介绍

Apache SkywalkingApache基金下由国人开发的分布式链路追踪系统,Skeywalking可以为微服务,云原生应用提供可视化链路追踪服务,通过Skywalking可以方便的查看服务的调用链路和性能瓶颈。 ELK是三个项目首字母的缩写,分别为Elasticsearch、Logstash 和 Kibana,Elasticsearch 是一个搜索和分析引擎。Logstash 是服务器端数据处理管道,能够同时从多个来源采集数据,转换数据,然后将数据发送到诸如 Elasticsearch 等“存储库”中。Kibana 则可以让用户在 Elasticsearch 中使用图形和图表对数据进行可视化。通过ELK用户可以在Kibana中方便查询应用日志,借助Elasticsearch强大的搜索能力,对于大数据量的日志也能进行快速检索。

Skywalking和ELK的集成,实际上就是将日志和调用链路关联起来,在交易出问题需要排查时,可以在Skeywalking查看其调用链路以及调用时长,到具体日志,需要到ELK中进行查看,两个系统需要有个标识符能够将其关联起来,这个标识符就是Trace id,skywalking会为每一笔交易生成一个traceid,在服务的调用链中会将该id传递到各个调用节点,服务在打印日志时,需要将该id带上,这样就能将其关联起来。

Read the rest of this entry

,

0x00 介绍

grafana是一款开源的数据可视化产品,支持prometheus等多种数据源,界面效果炫丽,操作方便灵活,支持大屏展示模式。grafana是目前最适合做prometheus数据可视化的产品,虽然prometheus也提供了可视化功能,但功能太弱无法满足大部分生产需求,prometheus的强项在于数据存储和数据查询,grafana的强项在于数据展示,两个系统配合就能打造强大的监控系统。

0x01 QuickStart

我们通过一个展示cpu使用率的面板来快速上手grafana

配置数据源

我们首先需要配置一个数据源,在界面点击Configuration-> Data Sources进入数据源创建界面,选择Prometheus数据源

Read the rest of this entry

,

0x00 功能介绍

  • 首页:首页搜索框可以输入PromQL进行数据查询,其中Graph可以按照时间维度做简单可视化
  • Alert:预警配置
  • Status:查看Prometheus系统状态,包括数据库状态,配置信息,监控目标状态等
Status->Target可以查看所有监控目标的情况,up表示运行正常,DOWN表示服务未启动

0x01 PromQL

介绍

PromQL是prometheus数据查询语言,类似SQL,通过SQL语句可以查询SQL数据库,同样,我们也可以通过PromQL查询prometheus数据库数据,prometheus数据库为时序数据库,指标数据存储都会带上时间标签,指标数据就是一组类似key-value的数据,比如以下是node-exporter部分metric数据

Read the rest of this entry

,

0x00 介绍

本文介绍如何在kubernetes环境中部署一整套完整的prometheus监控系统,涉及内容和知识点较多,部署过程相对上文也复杂不少,如果不是kubernetes环境的同学可以跳过该文,直接阅读下一篇,以免被复杂的操作劝退。本文包括以下内容

  • 部署prometheus
  • 部署grafana
  • 部署node-exporter
  • 部署kube-state-metrics
  • 部署alertmanager

Read the rest of this entry

,

0x00 概述

prometheus+grafana是目前较为流行的开源监控解决方案,prometheus丰富的exporter加上grafana灵活的配置以及炫酷的仪表盘界面基本满足系统的日常监控需求,搭建一个完整的监控系统需要安装以下程序

  • prometheus:负责数据存储和数据查询
  • grafana:负责数据展示
  • exporter:负责数据收集,不同的场景会有不同的exporter,基本上常用的场景都有相应的exporter,本文安装了node-exporter作为示例,node-expoerter负责收集主机相关信息
  • alertmanager:负责预警通知

另外本文会介绍两种安装方式,二进制程序安装和docker安装,读者可根据需要自行选择安装方式

如果只是想快速搭建prometheus环境用于技术研究,建议用docker方式进行安装

Read the rest of this entry

,

背景

在之前的文章中介绍如何用docker编译前端项目,docker编译项目的有点前面已经说的很清楚了这边就不在赘述,后端开发语言较多,我们就以java为例,介绍如何用maven镜像进行编译

实现

  • 我们准备一个java项目,使用maven进行包管理
  • 执行以下命令进行编译
docker run -it --rm --name my-maven-project -v "/you/path/app":/usr/app -w /usr/app maven:3.8.1-openjdk-8-slim mvn clean package

将项目挂载到容器文件系统路径/usr/app下,-w将工作目录指定到/usr/app下,–rm可以保证编译完删除镜像,避免占用空间。

首次编译因为本地没有下载依赖所以会先下载依赖包,再执行编译打包命令,这个结果不是我们想要的,如果一个工程依赖的包很多,每次都要重新下载效率会非常低,其实只要把maven的repository目录映射出来就行

Read the rest of this entry

介绍

nodejs官方提供docker镜像,并且镜像自带npm工具,也就是说,完全可以用docker镜像编译本地前端项目,那相比本地安装nodejs编译,docker编译有哪些优势呢

  • 可以安装多个版本nodejs,可以选择指定版本nodejs进行编译,如果你是要搭建一个构建平台,这是个非常好的方案
  • 免安装,如果需要安装多版本nodejs,这个优势就很明显了
  • 不会污染本地环境

如果你是个人开发,使用docker编译项目相对有点极客行为,在个人开发上并没有太大的优势,但是如果你是要搭建一个构建系统,那么docker镜像的方案是你最好的选择。

实现

虽然nodejs官方提供了镜像但实践下来如果直接用官方的镜像,无法达到想要的效果,原因有以下几点

Read the rest of this entry

介绍

nodejs官方提供docker镜像,并且镜像自带npm工具,也就是说,完全可以用docker镜像编译本地前端项目,那相比本地安装nodejs编译,docker编译有哪些优势呢

  • 可以安装多个版本nodejs,可以选择指定版本nodejs进行编译,如果你是要搭建一个构建平台,这是个非常好的方案
  • 免安装,如果需要安装多版本nodejs,这个优势就很明显了
  • 不会污染本地环境

如果你是个人开发,使用docker编译项目相对有点极客行为,在个人开发上并没有太大的优势,但是如果你是要搭建一个构建系统,那么docker镜像的方案是你最好的选择。

实现

虽然nodejs官方提供了镜像但实践下来如果直接用官方的镜像,无法达到想要的效果,原因有以下几点

  • nodejs项目初衷是用javascript作为后端预言,所以镜像主要是用于后端服务
  • 镜像虽然自带了npm工具,但因为WORKDIR的关系无法正常编译,尝试过多种方法还是无法顺利编译
  • 基于官方的镜像做二次构建成本很低,所以建议根据自己的需求做二次构建

我们先实现一个npm install功能的镜像

Read the rest of this entry

如果客户提出一个需求要在网页打开计算器,你可千万别以为是很简单的事,事实上,如果不借助“外力”是根本办不到。

背景

某项目客户提了这么一个需求

  • 需要在chrome浏览器中打开IE和firefox
  • 需要在firefox中打开IE和chrome
  • 需要在IE中打开firefox和chrome

总结下就是能在任意浏览器中打开任意浏览器,乍听之下觉得很扯是不是,觉得是个傻逼需求是不是,事实上,我的第一反应也是这样的,但了解事情背景后发现这是个很合理的需求,背景是客户有几个个遗留的老系统,其中核心业务系统只能运行在IE上,某BI系统只能运行在firefox上,你可能觉得很奇怪,只支持IE这个可以理解,只支持firefox这个有点匪夷所思,但事实确实如此,我们也不必去深究,现在客户要做门户,需要在门户上单点到所有系统,那么就有了上面的需求。

沙盒模型

想象一下如果javascript能读写本地文件会发生什么事

  • 打开百度你的资料可能就全部泄漏了
  • 打开百度可能就给你悄悄装上全家桶了
  • 打开百度你的盘可能就被格式化了
  • …..

Read the rest of this entry

背景

客户有一个java应用比较耗内存,在kubernetes上对cpu和内存进行了限制,但效果不大好,应用经常被kill掉,由于该应用属于核心应用,后面就解除限制,在jvm上对堆内存进行了限制,因为没有配置kubernetes资源请求限制,kubernetes在调度上就无法灵活调度,经常将多个副本调度到同一节点,多个大内存应用运行在同一个节点,内存很容易就被耗尽导致jvm gc频繁,频繁的gc又导致了服务器cpu负载过大,最终应用挂掉无法访问。如果kubernetes能将应用多个副本调度到不同节点那么至少能保证一个节点挂掉,其他节点应用还可以继续服务。

方案

  • DaemonSet

首先想到的是DaemonSet,DaemonSet能保证应用跑在不同的节点,但DaemonSet应用场景一般是作为守护进程或者日志收集,并且每个节点都会部署一个副本,这并不是我们想要的结果,因此不考虑DaemonSet。

Read the rest of this entry