grafana

点击上方 “ 民工哥技术之路 ” 选择“星标” 每天 10点 为你 分享 不一样的干货 读者福利！多达 2048G 各种资源免费赠送 作者：又耳笔记 原文：https://blog.51cto.com/youerning/2050543 前言: 笔者看来, 监控不应该只是监控，除了及时有效的报警，更应该”好看”，因为视觉上的感受更能给我们直观的感受，更能从绚丽的走势中发现异常, 如果你觉得监控就应该像老牌监控nagios,cacti一样，我想也没什么不对的，因为也许那是你们最适合的，但，你还是可以瞧瞧这个监控能给你带来什么。 效果图 为了你能有更多的动力看下去，这里放一部分通过Prometheus + grafana打造出来的监控平台，效果图如下。 如果你觉得不错可以继续看下去，上面主要是kvm宿主机, ceph集群, 物理机监控，以及ping, 最后一张的监控图没有展开是为了让你可以瞥一眼所能监控的指标条目。 Prometheus架构图 参考:https://prometheus.io/docs/introduction/overview/ 如果你对Prometheus没有接触过，也许会看不懂上面说什么，但是没关系，如果你看完之后，在回过头来瞧瞧，也许就了解这个架构了，也会对Prometheus有一个更深的认识。 这里简单说一下Prometheus的各个部分。

这20个Docker Command，有几个是你会的？ 收录于话题 #Docker 专辑 9个 点击上方“民工哥Linux运维”，选择“置顶公众号” 有趣有内涵的文章第一时间送达！ 在这之前呢，也写过两篇关于Docker基础入门类的文章 Docker容器技术入门（一） Docker容器技术入门（二） 很多人都感觉这文章这么简单、这么基础，可是别忘记了“万丈高楼平地起”，如果少了这个平地址，你这高楼估计也起不了。所以，基础是学习任何一门技术或者一个技术点的重中之重，也可以说是很关键的决胜点。 所以呢，今天，民工哥给大家总结了这20个Docker Command，愿各位小伙伴在通往“玩转Docker”路上不再无助!!!! 安装完成docker容器服务之后，需要了解如何操作它？在shell命令行下直接输入docker就可以查看帮助信息，如下。 [root@master ~]# docker Usage: docker COMMAND A self-sufficient runtime for containers Options: --config string Location of client config files (default "/root/.docker") -D, --debug Enable debug mode --help Print usage -H, -

喜欢就关注我们吧！ Kuma 1.0 GA 现已发布，包含了 70 多种新功能和改进。Kuma 是一个现代的通用服务网格控制平面，基于 Envoy 搭建，Envoy 是一个为云原生应用设计的强大的代理软件。 Kuma 高效的数据平面和先进的控制平面，极大地降低了各团队使用的难度，可以在包括 Kubernetes、虚拟机、容器、裸机和传统环境在内的任意平台上运行，以落实整个组织中的云原生体验。 此版本主要更新内容包括有： 多区域 自动生成“区域”资源，简化了多区域部署。 本地感知的负载平衡可减少多区域延迟并降低出口成本。 通过新的 "Ingress"DP 类型将入口数据平面代理自动同步到全局 CP。 Services & Policies 增加了对显式外部服务的支持。 增加了对新的“服务”资源的支持，该资源将每个“kuma.io/service”分组为多个数据平面代理。 添加了对 Kafka 协议的支持。 “网格”资源中的可配置 pass-through 控制功能。 性能 在关键任务 SLA-enforced 的企业环境中进行了生产中的实战测试。 在 Kuma 中运行成千上万的服务时，整体性能有了显着提高（〜5 倍）。 资源内部缓存的改进，以更好地支持高数据平面代理负载。 使用大量资源运行时，提高了 CLI 和 GUI 的总体可伸缩性。 安全

本文根据石鹏老师在〖deeplus直播第227期〗线上分享演讲内容整理而成。 （文末有获取本期PPT&回放的方式，不要错过） 我们都知道SRE是一个体系化的工程，SRE体系的建设涉及的内容繁多，比如日常需求处理、容量规划、资源部署、监控告警、预案梳理、灾备演练、OnCall值班、应急事件响应、故障处理、运维自动化建设等等；其中「故障」可以算作是这众多事项的一个交汇点。 故障处理是一个特别符合“台上一分钟，台下十年功”这句俗语的场景，一次故障就是一次考试。SRE团队的响应速度、对服务的掌控能力、监控告警的覆盖是否完整、配置是否合理，灾备预案的体系是否完善、是否做了充分的灾备演练、应急预案是否有效....这些都是用于考核SRE体系建设水平的一些指标，都会在「故障处理」的过程中得到淋漓尽致的体现。不管你是研发、测试、运维，或其他“工种”，只要你身处IT行业，「故障」怕都是大家避之唯恐不及却无法绕开的一个梦魇和话题。 我将围绕「故障管理」这个点跟大家聊一聊SRE的工作范畴，跟大家共同探讨SRE体系的建设。希望可以通过分享让大家对故障管理有一个宏观的框架，可以更从容淡定、有章可循地做服务稳定性建设。 本次分享将按照如下的顺序展开： 先聊一聊SRE的工作职责，聊一下我所理解的SRE的核心目标； 初步看一下稳定性建设的工作范畴，看一看从宏观上如何划分我们的工作内容； 然后我们由此进入今天的主题

1. 相关资料 官网部署资料 2. 独立mysql部署 mysql版本 5.7+ 2.1 初始化数据库 独立安装mysql, 创建数据库nacos, 执行脚本 nacos-db.sql 2.2 docker部署 nacos-server docker run -d \ -v /standalone-logs/:/home/nacos/logs -v ./custom.properties:/home/nacos/init.d/custom.properties -e PREFER_HOST_MODE=ip \ -e MODE=standalone \ -e SPRING_DATASOURCE_PLATFORM=mysql \ -e MYSQL_MASTER_SERVICE_HOST=10.5.96.32 \ -e MYSQL_MASTER_SERVICE_PORT=3306 \ -e MYSQL_MASTER_SERVICE_USER=root \ -e MYSQL_MASTER_SERVICE_PASSWORD=123456 \ -e MYSQL_MASTER_SERVICE_DB_NAME=nacos \ -e MYSQL_SLAVE_SERVICE_HOST=从数据库ip \ -p 7110:8848 \ -p 7111:9555 \ --name nacos1 \

本文原文2017年首发在我的个人博客 www.ipengtao.com ，今天想到后续文章可能会提及，提前给大家分享一下，方便提及的时候大家有印象。 之前给研发团队简单做了一次技术分享，主要讲了为什么我们要自己做监控，监控的指标维度，监控基本流程及常见监控工具介绍，最后如何从零快速开始搭建一套自己的监控工具，更多请在「涛哥聊Python」后台回复「 PPT 」。 工具介绍 1. Statsd 是一个使用Node开发网络守护进程，它的特点是通过UDP（性能好，及时挂了也不影响主服务）或者TCP来监听各种数据信息，然后发送聚合数据到后端服务进行处理。常见支持的「Graphite」，「ElasticaSearch」，「InfluxDB」 等等 ，它集成了各种语言的客户端API，这里我们使用了jsocol/pystatsd: A Python client for statsd进行数据收集。 2. Graphite 是一套Python写的开源编程接口，主要是用来收集服务器的及时状态，在这里主要作为statsd的数据后端。分为了三个子项目 - carbon 守护进程，接收StatsD发送过来的原始统计数据。 - whisper 用来存储统计数据 的时间序列数据库。 - graphite webapp 用来图形化展示统计数据的web项目 3. Grafana 使用Go开发

我们在发布一个 go 应用时，默认都会启用两个 http handler: 一个是 pprof，方便线上动态追踪问题；另外一个是 prometheus 的 metrics，这样就可以通过 grafana 准实时的监控当前 runtime 信息，及时预警。就像下面这样： package router import ( "net/http" _ "net/http/pprof" "github.com/prometheus/client_golang/prometheus/promhttp" ) func InitAdmin () { adminRouter := http . DefaultServeMux adminRouter . Handle ( "/metrics" , promhttp . Handler ()) adminServer = & http . Server { Addr : ":8081" , Handler : adminRouter , } go func () { if err := adminServer . ListenAndServe (); err != nil { println ( "ListenAndServe admin: " , err . Error ()) } }() } 最近我在优化一个 push 服务的时候，便观察到了一个

Nginx 是一个开源、免费、高性能的 HTTP 和反向代理服务器，也可以用于 IMAP/POP3 代理服务器。充分利用 Nginx 的特性，可以有效解决流量高并发请求、cc ***等问题。 本文探讨了电商场景下 Nginx 的监控方案，并将使用过程中遇到的问题和解决方案与大家一起分享。 Nginx 特性 作为 Web 服务器，Nginx 不免要与 Apache 进行比较。 相比 Apache 服务器，Nginx 因其采用的异步非阻塞工作模型，使其具备高并发、低资源消耗的特性，高度模块化设计使 Nginx 具备很好的扩展性；在处理静态文件、反向代理请求等方面，Nginx 表现出很大的优势。 Nginx 常见的使用方式 Nginx 可以作为反向代理服务器来转发用户请求；并能够在处理请求的过程中实现后端实例负载均衡，实现分发请求的功能；也可将 Nginx 配置为本地静态服务器，处理静态请求。 Nginx 监控 监控指标梳理 Nginx 处理请求的全过程应被监控起来，以便我们及时发现服务是否能够正常运转。 Nginx 处理请求的过程被详细地记录在 access.log 以及 error.log 文件中，我们给出以下（表 1）需要监控的关键指标： 表1：关键指标 监控实践 下面从延迟、错误、流量以及饱和度四个指标对 Nginx 监控实践进行说明。 延迟监控 延迟监控主要关注对

需求 公司项目采用微服务的架构，服务很多，每个服务都有自己的日志，分别存放在不同的服务器上。当查找日志时需要分别登录不同的服务器，有大量的请求的情况下，在日志文件中查找信息十分困难。想要搭建一个日志系统，ELK分布式日志系统对于中小型公司来说开发维护成本太高，经过调研，选择Loki轻量级日志系统。 Loki简介 Loki 是一个水平可扩展，高可用性，多租户日志聚合系统,灵感来自 Prometheus ，其设计非常经济高效，易于操作。它不索引日志的内容，而是为每个日志流设置一组标签。 Loki与其他日志聚合系统差别： 不对日志进行全文本索引。通过存储压缩的，非结构化的日志以及仅索引元数据，Loki更加易于操作且运行成本更低。 使用与Prometheus相同的标签对日志流进行索引和分组，从而使您能够使用与Prometheus相同的标签在指标和日志之间无缝切换。 特别适合存储Kubernetes Pod日志。诸如Pod标签之类的元数据会自动被抓取并建立索引。 在Grafana中原生支持（需要Grafana v6.0及以上）。 Loki的日志系统的组件： Promtail是代理，负责收集日志并将其发送给Loki。 Loki是主服务器，负责存储日志和处理查询。 Grafana用于查询和显示日志。 搭建步骤 本文采用的搭建方式是分别下载各个组件并安装。也可以参考官方的文档进行搭建安装。

1. 容器监控方案选择 对于容器的监控方案可谓多种多样，本身自带 docker stats 命令，Scout，Data Dog，Sysdig Cloud，Sensu Monitoring Framework，CAdvisor 等。 通过 docker stats 命令可以很方便地看到当前宿主机上所有容器的 CPU、内存以及网络流量等数据。但是 docker stats 命令的缺点就是统计的只是当前宿主机的所有容器，而获取的监控数据是实时的，没有地方存储，也没有报警功能。 而 Scout、Sysdig Cloud、Data Dog 虽然都提供了较完善的服务，但是它们都是托管的服务而且都收费，Sensu Monitoring Framework 集成度较高，也免费，但是部署过于复杂。综合考虑，选择 CAdvisor 做容器监控工具。 CAdvisor 谷歌出品，优点是开源产品，监控指标齐全，部署方便，而且有官方的 Docker 镜像。缺点是集成度不高，默认只在本地保存 2 分钟数据。不过可以加上 InfluxDB 存储数据，对接 Grafana 展示图表，比较顺利地搭建好了容器监控系统，数据收集和图表展示效果良好，对系统性能也几乎没有什么影响。 2. CAdvisor CAdvisor 是一个容器资源监控工具，包括容器的内存、CPU、网络 IO、磁盘 IO 等监控，同时提供了一个