kibana

ELK菜鸟手记 (三) - X-Pack权限控制之给Kibana加上登录控制以及index_not_found_exception问题解决 参考文章： （1）ELK菜鸟手记 (三) - X-Pack权限控制之给Kibana加上登录控制以及index_not_found_exception问题解决 （2）https://www.cnblogs.com/davidgu/p/6785039.html 备忘一下。 来源： oschina 链接： https://my.oschina.net/stackoom/blog/4681858

这篇博文的面向群体是 还不太了解 Prometheus 和 想要开始使用 Prometheus 的人群. 本文想做的事是 想尽力讲清楚 Prometheus 是如何看待监控这件事情 以及 Prometheus 是如何实现这些需求的. 本文中不会出现的内容: 跟 Prometheus 实现细节有太多相关的东西 等 当想看监控的时候, 我们到底想要什么? 我们想要看的东西也就是我们对监控的需求. 需求 在实际的生产过程中, 产生的和需要收集的监控数据分为很多种, 例如以下这些, 除此之外, 还有很多很多. 但从实现方式上来说, 大多都大同小异. 瞬时状态的 CPU 和 MEM 使用率读数 硬盘使用量的增长率 对 集群节点 状态 进行筛选 , 记录节点位于什么时刻不可用, 这就要求有 Tag 支持 瞬时状态的 网卡流量, 例如 100 Mbps, 服务请求量, 服务的 QPS, 服务的 错误率和错误次数 全部请求的平均时耗 一段时间内, 所有请求的 时耗中, 50% 的请求时耗小于多少毫秒, 95% 的请求时耗小于多少毫秒? 以此评估整体的接口情况 一段时间内, 所有请求的 时耗中, 多少请求时耗大于 1000ms, 多少请求时耗位于 200-500 区间内, 用于了解 请求时耗的具体分布, 以评估接口情况 …… 那么我们就需要一个 监控系统 来完成 上述需求, 这个监控系统

技术只是基础 　　该系列的两篇文章《 .Net微服务实战之技术选型篇 》和《 .Net微服务实战之技术架构分层篇 》都是以技术角度出发描述微服务架构的实施。 　　如果技术选型篇叙述的是 工具 ，那么架构分层篇讲的就是 技巧 ，而本篇要讨论的就是 原则 。一直以来我会给身边向我探讨问题的人灌输一种理念，没有什么技术银弹，因为我们做的是软件工程，提供的是问题相应的解决方案，不同类型问题的解决方案是存在着本质上的差异。 　　继续提供之前的源码：https://github.com/SkyChenSky/Sikiro PS：该篇文章与.Net无关，其实主要是沿用前面两篇文章的命名，此外我认为DevOps不是简单的工具使用，应从软件工程角度进行出发。 什么才是优秀的架构设计？ 　　曾经有好几个同行问过我同一个问题：什么才是优秀的架构设计？我一直信奉着 两句话 和 一个定律 ： 架构服务于业务，技术服务于架构 康威定律（简单理解成组织架构的设计等同于系统架构的设计） 　　 架构设计 其实就是一种 方案 的 取舍 ，在 有限 的 资源 里(包括但不限人力、时间)能让 团队 顺利的实施技术，同时满足 业务规模 的需要，我认为可以称之为优秀的架构设计，简单来说两个字 合适 架构核心要素 　　核心的主要5大： 性能、可用性、伸缩性、扩展性、安全性 。 　　而我们所讨论的微服务，选择了扩展性

Docker 安装单机版ELK日志收集系统 概述 现在Elasticsearch是比较火的, 很多公司都在用. 而Docker也正如火如荼, 所以我就使用了Docker来安装ELK, 这里会详细介绍下安装的细节以及需要注意的地方. 先来强调一下, Elasticsearch和Kibana必须用相同版本, 这个可以避免很多坑。 日志主要包括系统日志、应用程序日志和安全日志。系统运维和开发人员可以通过日志了解服务器软硬件信息、检查配置过程中的错误及错误发生的原因。经常分析日志可以了解服务器的负荷，性能安全性，从而及时采取措施纠正错误。 开源实时日志分析ELK平台由ElasticSearch、Logstash和Kiabana三个开源工具组成： 1）ElasticSearch是一个基于Lucene的开源分布式搜索服务器。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是第二流行的企业搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。在elasticsearch中，所有节点的数据是均等的。 2）Logstash是一个完全开源的工具

一、es启动报错： elasticsearch启动时报错： Java HotSpot™ 64-Bit Server VM warning: INFO: os::commit_memory(0x00000000e5330000, 449642496, 0) failed; error=‘Cannot allocate memory’ (errno=12) 报错信息：服务器运行内存不足 查看jvm.options配置文件 经查看原es运行内存给了16G，因服务器本身内存不足，导致服务无法运行，将es运行内存调小或者服务器增加内存，这里用到的办法就是降低es运行内存 vim jvm.options （此值根据服务器实际性能调整） 二、kiaban无法显示图 查看kibana索引状态 修改kaibana索引状态 解决办法 经过分析，发现是因为ES所在服务器磁盘空间太低引起，具体解决办法如下： 在kibana开发控制台执行下面语句即可： PUT _settings { "index": { "blocks": { "read_only_allow_delete": "false" } } } 三、最后解决 来源： oschina 链接： https://my.oschina.net/u/4356644/blog/4643185

ElasticSearch 概述 Elaticsearch ，简称为 es ， es 是一个开源的 高扩展 的 分布式全文检索引擎 ，它可以近乎 实时的存储、检 索数据 ；本身扩展性很好，可以扩展到上百台服务器，处理 PB 级别（大数据时代）的数据。 es 也使用 Java 开发并使用 Lucene 作为其核心来实现所有索引和搜索的功能，但是它的目的是通过简单的 RESTful API 来隐藏 Lucene 的复杂性，从而让全文搜索变得简单。 据国际权威的数据库产品评测机构 DB Engines 的统计，在 2016 年 1 月， ElasticSearch 已超过 Solr 等， 成 为排名第一的搜索引擎类应用。 历史 多年前，一个叫做 Shay Banon 的刚结婚不久的 失业开发者 ，由于妻子要去伦敦学习厨师，他便跟着也去 了。在他找工作的过程中，为了给妻子构建一个食谱的搜索引擎，他开始构建一个早期版本的 Lucene 。 直接基于 Lucene 工作会比较困难，所以 Shay 开始抽象 Lucene 代码以便 Java 程序员可以在应用中添加搜 索功能。他发布了他的第一个开源项目，叫做 “Compass” 。 后来 Shay 找到一份工作，这份工作处在高性能和内存数据网格的分布式环境中，因此高性能的、实时 的、分布式的搜索引擎也是理所当然需要的。然后他决定重写

环境介绍 为简化安装和升级，Elastic Stack各组件版本是同步发布的。本次安装，采用最新的7.9通用版。官方有多种安装方式：tar、rpm、docker、yum形式，我选择用tar包安装。 Elastic Stack 组件： Beats7.9 （filebeat) Elasticsearch7.9 Kibana7.9 Logstash7.9 操作系统：CentOS8.2.2004 JDK版本：jdk-14.0.2_linux-x64_bin.rpm（Logstash依赖JDK） Redis版本：5.0.3 (yum 安装) 下载地址： https://artifacts.elastic.co/downloads/kibana/kibana-7.9.0-linux-x86_64.tar.gz https://artifacts.elastic.co/downloads/logstash/logstash-7.9.0.tar.gz https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.9.0-linux-x86_64.tar.gz https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.9.0-linux-x86_64

一、 简介 Elasticsearch是一个高度可扩展的开源全文搜索和分析引擎。它允许您快速，近实时地存储，搜索和分析大量数据。它通常用作支持具有复杂搜索功能和需求的应用程序的底层引擎/技术。 架构图： 二、安装前准备 服务器环境 Node1: ES、 Node2： ES、filebeat、logstash Node3： ES、kibana 1、系统优化（在正式安装前需要进行系统优化，负责无法启动） 单个JVM下支撑的线程数 vim /etc/sysctl.conf vm.max_map_count=655360 vm.swappiness=0 修改文件句柄数 root用户设置 vim /etc/security/limits.conf root soft nofile 65535 root hard nofile 65535 * soft nofile 65536 * hard nofile 65536 * soft memlock unlimited * hard memlock unlimited 普通账户设置 （es使用非root启动） vim /etc/security/limits.d/20-nproc.conf * soft nproc 65535 * hard nproc 65535 root soft nproc unlimited 2、基础环境 #配置主机名

一：背景 1. 讲故事 在开始本文之前，真的好想做个问卷调查，到底有多少人和我一样，对 JsonConvert 的认识只局限在 SerializeObject 和 DeserializeObject 这两个方法上(┬＿┬), 这样我也好结伴同行，不再孤单落魄，或许是这两个方法基本上能够解决工作中 80% 的场景，对于我来说确实是这样，但随着编码的延续，终究还是会遇到那剩下的 20% ，所以呀。。。 我的场景是这样的：前段时间写业务代码的时候，我有一个自定义的客户算法类型的Model，这个Model中有这种算法类型下的客户群以及Report统计信息，还用了 HashSet 记录了该类型下的 CustomerID集合，为了方便讲述，我把Model简化如下： class CustomerAlgorithmModel { public string DisplayName { get; set; } public int CustomerType { get; set; } public ReprotModel Report { get; set; } public HashSet<int> CustomerIDHash { get; set; } } class ReprotModel { public int TotalCustomerCount { get; set; }