grafana

Prometheus is an open-source systems monitoring and alerting toolkit originally built at SoundCloud. 1、Features Prometheus's main features are: a multi-dimensional data model with time series data identified by metric name and key/value pairs PromQL, a flexible query language to leverage this dimensionality no reliance on distributed storage; single server nodes are autonomous time series collection happens via a pull model over HTTP pushing time series is supported via an intermediary gateway targets are discovered via service discovery or static configuration multiple modes of graphing and

监控系统是运维体系乃至整个软件产品生命周期中最重要的一环，完善的监控可以帮助我们事前及时发现故障，事后快速追查定位问题。而在以微服务为代表的云原生架构体系中，系统分为多个层次，服务之间调用链路复杂，系统中需要监控的目标非常多，如果没有一个完善的监控系统就难以保证整体服务的持续稳定。 监控对象及分层 在实际场景中监控系统按照监控的对象及系统层次结构，从底向上可以依次划分为基础层、中间层、应用层、业务层等多个层面的监控。具体可如图所示： 基础层监控就是对主机服务器(包括宿主机、容器)及其底层资源进行监控，以保证应用程序运行所依赖的基础环境的稳定运行。基础层监控主要有两个方向： 资源利用：是对像I/O利用率、CPU利用率、内存使用率、磁盘使用率、网络负载等这样的硬件资源进行监控。避免因应用程序本身或其它特殊情况引起的硬件资源耗尽而出现的服务故障。 网络通信：是对服务器之间的网络状态进行监控。网络通信是互联网的重要基石，如果主机之间的网络出现如延迟过大、丢包率高这样的网络问题，将会严重影响业务。 需要说明的是，在基于Kubernetes容器化技术的新型云原生基础设施中，基础层的监控不仅要对宿主机本身进行监控，也要对Kubernetes集群状态及其容器资源使用情况进行监控。这在后面我们构建基于Kubernetes的基础层监控体系时将会具体介绍。 中间层监控主要是指对诸如Nginx、Redis

随着微服务架构的流行，迈向云原生的趋势，容器化微服务就成为了持续集成最好的手段，镜像成为了持续交付最好的产物，容器成为了镜像运行最好的环境， kubernetes 成了部署容器最好的生态系统和规范。实践出真知，自学习 kubernetes 以来，写了一系列文章，首先，为了发现知识盲点，查漏补缺，将知识点形成体系，决定将之前写的文章做一个汇总，方便查看；其次，希望打通微服务落地 kubernetes 的任督二脉，探索出一种工作模式，建立一条高度自动化的流水线，于是踏上了西天取经的道路，并梳理出了西游路线图，希望大家和我一起打妖怪，早日到达雷音寺，取得真经，阿弥陀佛，成佛成仙，呵呵；最后，通过梳理明确学习的方向和目标，一步一步前进，勿急勿躁，也鞭策自己不断学习、探索，因为有时真的就懒惰了，嘿嘿，正如四书五经《大学》中所言：“知止而后有定，定而后能静，静而后能安，安而后能虑，虑而后能得”，这是我最喜欢的话之一，也是懒惰时常常会想起的一句话，好了，不扯犊子了，嘿嘿。 西游路线图(不断探索中...)： 持续集成 --- development 阶段 代码提交、代码审核、构建编译、单元和功能测试、合并到代码仓库(git)、打包微服务成镜像、上传到镜像仓库 --- 全自动化。 备注：持续集成流程非常重要，特别是互联网行业，产品不断的更新迭代，周期却很短，业务系统微服务化后

在过去的几年中，我们已经看到 Kubernetes 被广泛用作容器编排平台。随之而来的还有不同的方式来操作 Kubernetes 集群。一些企业更喜欢一个集群一租户（硬多租户），而另一些企业更喜欢一个集群 n 租户（软多租户）模型。我们已经看到许多企业都采用后一种模型，因为它可以帮助他们减少很多运营工作。对于软多租户模型，明智地提供成本分配租户的可见性非常重要，以便可以相应地向组织收费。 需求 我们正在运行一个软多租户 Amazon EKS 集群。使用 Kubernetes 命名空间可以实现多租户。现在用于成本报告，AWS 提供了成本资源管理器，如果您想对节点，EBS 和整个网络收取费用，这将非常有用。但是不可能使用它来实现共享资源或池化资源的成本分离。我们希望基于租户创建报告，以便可以将其与预算相对应。市场上有许多用于 Kubernetes 成本报告的解决方案，我们一直在寻找开源的东西，最终选择了 Kubecost。在此博客文章中，我将详细说明如何将 Kubecost 用于多租户 EKS 集群，以获得更好的可见性。 Kubecost Kubecost 可帮助您监视和管理 Kubernetes 环境中的成本和容量。- Kubecost 文档（ https://docs.kubecost.com/ ） Kubecost 既可以作为开源产品也可以作为商业产品。该商业产品具有少量附加功能

点击上方“ 民工哥技术之路 ”，选择“设为星标” 回复“ 1024 ”获取独家整理的学习资料！ 为什么要优化 Ngin HTTPS 延迟 Nginx 常作为最常见的服务器，常被用作负载均衡 (Load Balancer)、反向代理 (Reverse Proxy)，以及网关 (Gateway) 等等。一个配置得当的 Nginx 服务器单机应该可以期望承受住 50K 到 80K 左右每秒的请求，同时将 CPU 负载在可控范围内。 但在很多时候，负载并不是需要首要优化的重点。比如对于卡拉搜索来说，我们希望用户在每次击键的时候，可以体验即时搜索的感觉，也就是说，每个搜索请求必须在 100ms - 200ms 的时间内端对端地返回给用户，才能让用户搜索时没有“卡顿”和“加载”。因此，对于我们来说，优化请求延迟才是最重要的优化方向。 这篇文章中，我们先介绍 Nginx 中的 TLS 设置有哪些与请求延迟可能相关，如何调整才能最大化加速。然后我们用优化卡拉搜索Nginx 服务器的实例来分享如何调整 Nginx TLS/SSL 设置，为首次搜索的用户提速 30% 左右。我们会详细讨论每一步我们做了一些什么优化，优化的动机和效果。希望可以对其它遇到类似问题的同学提供帮助。 TLS 握手和延迟 很多时候开发者会认为：如果不是绝对在意性能，那么了解底层和更细节的优化没有必要。这句话在很多时候是恰当的