易语言如何做浏网站,百度网页制作,seo网站内容更新,上海交通网站建设目录
日志问题
责任链问题
分布式日志 GrayLog简介 部署安装 收集日志
配置Inputs
集成微服务
日志回收策略
搜索语法
搜索语法
自定义展示字段
日志统计仪表盘
创建仪表盘 链路追踪
APM
什么是APM
原理
技术选型
Skywalking简介
部署安装
微服务探针
整合…目录
日志问题
责任链问题
分布式日志 GrayLog简介 部署安装 收集日志
配置Inputs
集成微服务
日志回收策略
搜索语法
搜索语法
自定义展示字段
日志统计仪表盘
创建仪表盘 链路追踪
APM
什么是APM
原理
技术选型
Skywalking简介
部署安装
微服务探针
整合到docker服务 在微服务架构体系中微服务上线后有两个不容忽略的问题一是日志该怎么存储、查看二是如何在复杂的调用链中排查问题。
日志问题
在微服务架构下微服务被拆分成多个微小的服务每个微小的服务都部署在不同的服务器实例上当我们定位问题检索日志的时候需要依次登录每台服务器进行检索。
这样是不是感觉很繁琐和效率低下所以我们还需要一个工具来帮助集中收集、存储和搜索这些跟踪信息。
集中化管理日志后日志的统计和检索又成为一件比较麻烦的事情。以前我们通过使用grep、awk和wc等Linux命令能实现检索和统计但是对于要求更高的查询、排序和统计等要求和庞大的机器数量依然使用这样的方法难免有点力不从心。
所以需要通过分布式日志服务来帮我们解决上述问题的。
责任链问题 在微服务架构下如何排查异常的微服务比如发布新版本后发现系统处理用户请求变慢了要想解决这个问首先是要找出“慢”的环节此时就需要对整个微服务的调用链有清晰的监控否则是不容易找出问题的。
分布式日志
分布式日志框架服务的实现思路基本是一致的如下
日志收集器微服务中引入日志客户端将记录的日志发送到日志服务端的收集器然后以某种方式存储数据存储一般使用ElasticSearch分布式存储把收集器收集到的日志格式化然后存储到分布式存储中web服务利用ElasticSearch的统计搜索功能实现日志查询和报表输出
比较知名的分布式日志服务包括
ELKelasticsearch、Logstash、KibanaGrayLog
这里选择graylog实现分布式日志
业界比较知名的分布式日志服务解决方案是ELK而我们今天要学习的是GrayLog。为什么呢
ELK解决方案的问题
不能处理多行日志比如Mysql慢查询Tomcat/Jetty应用的Java异常打印不能保留原始日志只能把原始日志分字段保存这样搜索日志结果是一堆Json格式文本无法阅读。不符合正则表达式匹配的日志行被全部丢弃。
GrayLog方案的优势
一体化方案安装方便不像ELK有3个独立系统间的集成问题。采集原始日志并可以事后再添加字段比如http_status_coderesponse_time等等。自己开发采集日志的脚本并用curl/nc发送到Graylog Server发送格式是自定义的GELFFlunted和Logstash都有相应的输出GELF消息的插件。自己开发带来很大的自由度。实际上只需要用inotifywait监控日志的modify事件并把日志的新增行用curl/netcat发送到Graylog Server就可。搜索结果高亮显示就像google一样。搜索语法简单比如 source:mongo AND reponse_time_ms:5000避免直接输入elasticsearch搜索json语法搜索条件可以导出为elasticsearch的搜索json文本方便直接开发调用elasticsearch rest api的搜索脚本。 GrayLog简介
GrayLog是一个轻量型的分布式日志管理平台一个开源的日志聚合、分析、审计、展示和预警工具。在功能上来说和 ELK类似但又比 ELK要简单轻量许多。依靠着更加简洁高效部署使用简单的优势很快受到许多公司的青睐。
官网SIEM, Log Management API Protection
其基本框架如图
基本思路就是每一个微服务把自己的日志发送给GrayLog然后将日志数据存入mongoDB或者es中最后提供一个浏览器进行操作 流程如下
微服务中的GrayLog客户端发送日志到GrayLog服务端GrayLog把日志信息格式化存储到Elasticsearch客户端通过浏览器访问GrayLogGrayLog访问Elasticsearch
这里MongoDB是用来存储GrayLog的配置信息的这样搭建集群时GrayLog的各节点可以共享配置。 部署安装
我们在虚拟机中选择使用Docker来安装。需要安装的包括
MongoDB用来存储GrayLog的配置信息Elasticsearch用来存储日志信息GrayLogGrayLog服务端
下面将通过docker的方式部署镜像已经下载到101虚拟机中部署脚本如下 #部署Elasticsearch docker run -d \ --name elasticsearch \ -e ES_JAVA_OPTS-Xms512m -Xmx512m \ -e discovery.typesingle-node \ -v es-data:/usr/share/elasticsearch/data \ -v es-plugins:/usr/share/elasticsearch/plugins \ --privileged \ -p 9200:9200 \ -p 9300:9300 \ elasticsearch:7.17.5 #部署MongoDB使用之前部署的服务即可 docker run -d \ --name mongodb \ -p 27017:27017 \ --restartalways \ -v mongodb:/data/db \ -e MONGO_INITDB_ROOT_USERNAMEsl \ -e MONGO_INITDB_ROOT_PASSWORD123321 \ mongo:4.4 #部署 docker run \ --name graylog \ -p 9000:9000 \ -p 12201:12201/udp \ -e GRAYLOG_HTTP_EXTERNAL_URIhttp://192.168.150.101:9000/ \ -e GRAYLOG_ELASTICSEARCH_HOSTShttp://192.168.150.101:9200/ \ -e GRAYLOG_ROOT_TIMEZONEAsia/Shanghai \ -e GRAYLOG_WEB_ENDPOINT_URIhttp://192.168.150.101:9000/:9000/api \ -e GRAYLOG_PASSWORD_SECRETsomepasswordpepper \ -e GRAYLOG_ROOT_PASSWORD_SHA28c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918 \ -e GRAYLOG_MONGODB_URImongodb://sl:123321192.168.150.101:27017/admin \ -d \ graylog/graylog:4.3 命令解读 端口信息 -p 9000:9000GrayLog的http服务端口9000-p 12201:12201/udpGrayLog的GELF UDP协议端口用于接收从微服务发来的日志信息 环境变量 -e GRAYLOG_HTTP_EXTERNAL_URI对外开放的ip和端口信息这里用9000端口-e GRAYLOG_ELASTICSEARCH_HOSTSGrayLog依赖于ES这里指定ES的地址-e GRAYLOG_WEB_ENDPOINT_URI对外开放的API地址-e GRAYLOG_PASSWORD_SECRET密码加密的秘钥-e GRAYLOG_ROOT_PASSWORD_SHA2密码加密后的密文。明文是admin账户也是admin-e GRAYLOG_ROOT_TIMEZONEAsia/ShanghaiGrayLog容器内时区-e GRAYLOG_MONGODB_URI指定MongoDB的链接信息 graylog/graylog:4.3使用的镜像名称版本为4.3 访问地址 http://192.168.150.101:9000/ 如果可以看到如下界面说明启动成功。 收集日志
配置Inputs
部署完成GrayLog后需要配置Inputs才能接收微服务发来的日志数据。
第一步在System菜单中选择Inputs 第二步在页面的下拉选框中选择GELF UDP 然后点击Launch new input按钮 点击save保存 可以看到GELF UDP Inputs 保存成功。 集成微服务
现在GrayLog的服务端日志收集器已经准备好我们还需要在项目中添加GrayLog的客户端将项目日志发送到GrayLog服务中保存到ElasticSearch。
基本步骤如下
引入GrayLog客户端依赖配置Logback集成GrayLog的Appender启动并测试
这里我们以work微服务为例其他的类似。
导入依赖
dependencygroupIdbiz.paluch.logging/groupIdartifactIdlogstash-gelf/artifactIdversion1.15.0/version
/dependency
配置Logback在配置文件中增加 GELF的appender
logback-spring.xml
?xml version1.0 encodingUTF-8?
!--scan: 当此属性设置为true时配置文件如果发生改变将会被重新加载默认值为true。--
!--scanPeriod: 设置监测配置文件是否有修改的时间间隔如果没有给出时间单位默认单位是毫秒。当scan为true时此属性生效。默认的时间间隔为1分钟。--
!--debug: 当此属性设置为true时将打印出logback内部日志信息实时查看logback运行状态。默认值为false。--
configuration debugfalse scanfalse scanPeriod60 secondsspringProperty scopecontext nameappName sourcespring.application.name/!--文件名--property namelogback.appname value${appName}/!--文件位置--property namelogback.logdir value/data/logs/!-- 定义控制台输出 --appender namestdout classch.qos.logback.core.ConsoleAppenderlayout classch.qos.logback.classic.PatternLayoutpattern%d{yyyy-MM-dd HH:mm:ss.SSS} - [%thread] - %-5level - %logger{50} - %msg%n/pattern/layout/appenderappender nameFILE classch.qos.logback.core.rolling.RollingFileAppenderfilter classch.qos.logback.classic.filter.ThresholdFilterlevelDEBUG/level/filterFile${logback.logdir}/${logback.appname}/${logback.appname}.log/FilerollingPolicy classch.qos.logback.core.rolling.TimeBasedRollingPolicyFileNamePattern${logback.logdir}/${logback.appname}/${logback.appname}.%d{yyyy-MM-dd}.log.zip/FileNamePatternmaxHistory90/maxHistory/rollingPolicyencodercharsetUTF-8/charsetpattern%d [%thread] %-5level %logger{36} %line - %msg%n/pattern/encoder/appenderappender nameGELF classbiz.paluch.logging.gelf.logback.GelfLogbackAppender!--GrayLog服务地址--hostudp:192.168.150.101/host!--GrayLog服务端口--port12201/portversion1.1/version!--当前服务名称--facility${appName}/facilityextractStackTracetrue/extractStackTracefilterStackTracetrue/filterStackTracemdcProfilingtrue/mdcProfilingtimestampPatternyyyy-MM-dd HH:mm:ss,SSS/timestampPatternmaximumMessageSize8192/maximumMessageSize/appender!--evel:用来设置打印级别大小写无关TRACE, DEBUG, INFO, WARN, ERROR, ALL 和 OFF--!--不能设置为INHERITED或者同义词NULL。默认是DEBUG。--root levelINFOappender-ref refstdout/appender-ref refGELF//root
/configuration
加载这个文件
logging:config: classpath:logback-spring.xml
开启微服务进入打印日志便于查看数据启动服务点击search按钮即可看到日志数据 日志回收策略
到此graylog的基础配置就算完成了已经可以收到日志数据。
但是在实际工作中服务日志会非常多这么多的日志如果不进行存储限制那么不久就会占满磁盘查询变慢等等而且过久的历史日志对于实际工作中的有效性也会很低。
Graylog则自身集成了日志数据限制的配置可以通过如下进行设置 选择Default index set的Edit按钮 GrayLog有3种日志回收限制触发以后就会开始回收空间删除索引 分别是
Index Message Count按照日志数量统计默认超过20000000条日志开始清理 我们测试时设置100000即可
Index Size按照日志大小统计默认超过1GB开始清理Index Time按照日志日期清理默认日志存储1天 搜索语法
在search页面可以完成基本的日志搜索功能 搜索语法
搜索语法非常简单输入关键字或指定字段进行搜索
#不指定字段默认从message字段查询
输入undo
#输入两个关键字关系为or
undo 统计
#加引号是需要完整匹配
undo 统计
#指定字段查询level表示日志级别ERROR3、WARNING4、NOTICE5、INFO6、DEBUG7
level: 6
#或条件
level:(6 OR 7)
更多查询官网文档Write Search Queries
自定义展示字段 效果如下 日志统计仪表盘
GrayLog支持把日志按照自己需要的方式形成统计报表并把许多报表组合一起形成DashBoard仪表盘方便对日志统计分析。
创建仪表盘 可以设置各种指标 最终效果 官方给出的效果 链路追踪
APM
什么是APM
随着微服务架构的流行一次请求往往需要涉及到多个服务因此服务性能监控和排查就变得更复杂
不同的服务可能由不同的团队开发、甚至可能使用不同的编程语言来实现服务有可能布在了几千台服务器横跨多个不同的数据中心
因此就需要一些可以帮助理解系统行为、用于分析性能问题的工具以便发生故障的时候能够快速定位和解决问题这就是APM系统全称是Application Performance Monitor当然也有叫 Application Performance Management tools
原理
先来看一次请求调用示例
包括前端A两个中间层B和C以及两个后端D和E当用户发起一个请求时首先到达前端A服务然后分别对B服务和C服务进行RPC调用B服务处理完给A做出响应但是C服务还需要和后端的D服务和E服务交互之后再返还给A服务最后由A服务来响应用户的请求 如何才能实现跟踪呢需要明白下面几个概念
探针负责在客户端程序运行时收集服务调用链路信息发送给收集器收集器负责将数据格式化保存到存储器存储器保存数据UI界面统计并展示
探针会在链路追踪时记录每次调用的信息Span是基本单元一次链路调用可以是RPCDB等没有特定的限制创建一个span通过一个64位ID标识它同时附加Annotation作为payload负载信息用于记录性能等数据。
一个Span的基本数据结构
type Span struct {TraceID int64 // 用于标示一次完整的请求idName string //名称ID int64 // 当前这次调用span_idParentID int64 // 上层服务的调用span_id 最上层服务parent_id为null代表根服务rootAnnotation []Annotation // 记录性能等数据Debug bool
}
一次请求的每个链路通过spanId、parentId就能串联起来 当然从请求到服务器开始服务器返回response结束每个span存在相同的唯一标识trace_id。
技术选型
市面上的全链路监控理论模型大多都是借鉴Google Dapper论文重点关注以下三种APM组件
Zipkin由Twitter公司开源开放源代码分布式的跟踪系统用于收集服务的定时数据以解决微服务架构中的延迟问题包括数据的收集、存储、查找和展现。Pinpoint一款对Java编写的大规模分布式系统的APM工具由韩国人开源的分布式跟踪组件。Skywalking国产的优秀APM组件是一个对JAVA分布式应用程序集群的业务运行情况进行追踪、告警和分析的系统。现在是Apache的顶级项目之一。
选项就是对比各个系统的使用差异主要对比项
探针的性能 主要是agent对服务的吞吐量、CPU和内存的影响。微服务的规模和动态性使得数据收集的成本大幅度提高。collector的可扩展性 能够水平扩展以便支持大规模服务器集群。全面的调用链路数据分析 提供代码级别的可见性以便轻松定位失败点和瓶颈。对于开发透明容易开关 添加新功能而无需修改代码容易启用或者禁用。完整的调用链应用拓扑 自动检测应用拓扑帮助你搞清楚应用的架构
三者对比如下 对比项 zipkin pinpoint skywalking 探针性能 中 低 高 collector扩展性 高 中 高 调用链路数据分析 低 高 中 对开发透明性 中 高 高 调用链应用拓扑 中 高 中 社区支持 高 中 高
综上所述使用skywalking是最佳的选择。
Skywalking简介
SkyWalking创建与2015年提供分布式追踪功能是一个功能完备的APM系统。
官网地址Apache SkyWalking 主要的特征
多语言探针或类库 Java自动探针追踪和监控程序时不需要修改源码。社区提供的其他多语言探针 .NET CoreNode.js
多种后端存储 ElasticSearch H2支持OpenTracing Java自动探针支持和OpenTracing API协同工作
轻量级、完善功能的后端聚合和分析现代化Web UI日志集成应用、实例和服务的告警
官方架构图 大致分四个部分
skywalking-oap-server就是Observability Analysis Platform的服务用来收集和处理探针发来的数据skywalking-UI就是skywalking提供的Web UI 服务图形化方式展示服务链路、拓扑图、trace、性能监控等agent探针获取服务调用的链路信息、性能信息发送到skywalking的OAP服务Storage存储一般选择elasticsearch
因此我们安装部署也从这四个方面入手目前elasticsearch已经安装完成只需要部署其他3个即可。
部署安装 #oap服务需要指定Elasticsearch以及链接信息 docker run -d \ -e TZAsia/Shanghai \ --name oap \ -p 12800:12800 \ -p 11800:11800 \ -e SW_STORAGEelasticsearch \ -e SW_STORAGE_ES_CLUSTER_NODES192.168.150.101:9200 \ apache/skywalking-oap-server:9.1.0 #部署ui需要指定oap服务 docker run -d \ --name oap-ui \ -p 48080:8080 \ -e TZAsia/Shanghai \ -e SW_OAP_ADDRESShttp://192.168.150.101:12800 \ apache/skywalking-ui:9.1.0 启动成功后访问地址http://192.168.150.101:48080/即可查看skywalking的ui界面。 通过docker部署需要部署两部分分别是skywalking-oap-server和skywalking-UI。 #oap服务需要指定Elasticsearch以及链接信息 docker run -d \ -e TZAsia/Shanghai \ --name oap \ -p 12800:12800 \ -p 11800:11800 \ -e SW_STORAGEelasticsearch \ -e SW_STORAGE_ES_CLUSTER_NODES192.168.150.101:9200 \ apache/skywalking-oap-server:9.1.0 #部署ui需要指定oap服务 docker run -d \ --name oap-ui \ -p 48080:8080 \ -e TZAsia/Shanghai \ -e SW_OAP_ADDRESShttp://192.168.150.101:12800 \ apache/skywalking-ui:9.1.0 启动成功后访问地址http://192.168.150.101:48080/即可查看skywalking的ui界面。 微服务探针
现在Skywalking的服务端已经启动完成我们还需要在微服务中加入服务探针来收集数据。 将skywalking-agent解压到非中文目录。
在微服务中设置启动参数以work微服务为例 输入如下内容
-javaagent:F:\code\sl-express\docs\resources\skywalking-agent\skywalking-agent.jar
-Dskywalking.agent.service_namems::sl-express-ms-work
-Dskywalking.collector.backend_service192.168.150.101:11800
参数说明
javaagent 将skywalking-agent以代理的方式整合到微服务中skywalking.agent.service_name指定服务名称格式[{logic name}skywalking.collector.backend_service指定oap服务注意端口要走11800
设置完成后重新启动work微服务多请求几次接口即可自oap-ui中看到数据。 查看链路 服务关系拓扑图 整合到docker服务
前面的测试是在本地测试如何将SkyWalking整合到docker服务中呢
这里以sl-express-ms-web-courier为例其他的服务类似。
第一步修改Dockerfile文件
#FROM openjdk:11-jdk
#修改为基于整合了skywalking的镜像其他的不需要动
FROM apache/skywalking-java-agent:8.11.0-java11
LABEL maintainer研究院研发组 researchitcast.cn# 时区修改为东八区
ENV TZAsia/Shanghai
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime echo $TZ /etc/timezoneWORKDIR /app
ARG JAR_FILEtarget/*.jar
ADD ${JAR_FILE} app.jar
EXPOSE 8080
ENTRYPOINT [sh,-c,java -Djava.security.egdfile:/dev/./urandom -jar $JAVA_OPTS app.jar]
第二步在Jenkins中编辑修改配置
名称skywalkingServiceName 值ms::sl-express-ms-web-courier 名称skywalkingBackendService 值192.168.150.101:11800 修改运行脚本增加系统环境变量
-e SW_AGENT_NAME${skywalkingServiceName} -e SW_AGENT_COLLECTOR_BACKEND_SERVICES${skywalkingBackendService} 第三步重新部署服务 第四步测试接口查看数据。
