apm之对比 方案列表 以下包含部分主流的一站式方案和自建组合方案： skywalking zipKin opentelemetry agent + opentelemetry collector + jaeger/Tempo(traceing) + prometheus(metrics) + elasticsearch(log) opentelemetry agent + opentelemetry collector + elastic apm server elastic apm agent + elastic apm server 当然实际肯定不止这些方案，以上只是在查找资料过程中了解到的 方案对比 一个项目需要选择某个方案，肯定需要综合考虑，多维度对比产品的特点，以下是一些简单的分析： 体验测试过skywalking，支持无侵入，总体上还可以，但是使用这块意味着相对较为封闭，学习成本一般 zipKin，未测试使用，查资料需要手动埋点，意味着使用成本较高 比较标准的监控方案，分别使用不同组件来存储、分析、展示数据，组件根据实际要求可替换性很高，但缺点是组件太多 opentelemetry和elastic结合的方案，减少了部分组件，如果当前已经有elastic生态，那么是非常容易集成的，且依然满足随时替换后端的需求，可以按需调整 完全使用elastic的方案，优点可以直接集成，缺点是也相对封闭 基于以上的特性，此次选择方案4来测试使用

vps厂商 推荐 https://lisahost.com/ https://www.kvmla.pro/ Linode 目前也使用了两年的腾讯云香港轻量主机，效果也还不错 如果能搞到日本或者韩国的质量好的主机是最好的，延迟低，不过这种麻烦并且价格不低

H3C设备持久化日志到rsyslog服务器 0x1 why 原因很简单，设备日志没有持久化，不能在性能、故障、安全等问题过后进行排查 0x2 how 日志 buffer 默认只有 512 条，没有进行持久化，这里我们仅配置 h3c 设备如何发送日志到 rsyslog 服务器 先查看当前有哪些vlan，确定使用哪个vlan接口作为源地址发送给日志服务器 dis int vlan br 此示例设置vlan 1为日志发送的源地址和接口 info-center loghost source Vlan-interface 1 设置日志的发送事件类型，这里设置为local6，与rsyslog中的保持一致 info-center loghost 192.168.3.100 facility local6 查看配置内容，以及是否启用等 dis info-center 至此，如果rsyslog服务器已经配置完成的话，那么可以在相关目录查看到设备的日志文件了

rsyslog日志服务器配置 0x1 rsyslog 这里记录 rsyslog 的方式作为日志服务器持久化日志，为什么需要rsyslog呢？ 举一个身边常见的例子，常见的三层交换机、路由器等网络设备保存的日志条目只有512条，并且网络设备的日志量是不低的，那么意味着，如果有一个网络问题出现，想要排查之前十几分钟甚至半个小时的日志都非常困难，所以需要一个日志系统来持久化保存历史 0x2 为什么rsyslog 其实翻一翻文档可以看到，网络设备默认配置 syslog 协议发送日志到服务器，这部分已经能够被 logstash 替换了，所以最终我们的目标可以是，直接对接网络设备和 elfk。 但 syslog 胜在简单，如果小公司不想单独弄一个复杂的日志系统，那么简单的 rsyslog 服务器也是能够满足需求的 rsyslog 配置 这里以收集 H3C 设备日志为例，其中 H3C 的配置部分参考本站内的文档 H3C设备持久化日志到rsyslog服务器： 使用 yum 安装 rsyslog 修改 rsyslog 配置文件 /etc/rsyslog.conf，开启 udp 和 tcp 端口监听: # Provides UDP syslog reception $ModLoad imudp $UDPServerRun 514 # Provides TCP syslog reception $ModLoad imtcp $InputTCPServerRun 514 在文件的前面部分，默认是注释的，启动 rsyslog 服务不会监听，取消注释即可 在配置文件最后追加如下内容: $template h3c,"/data/logs/h3c/%FROMHOST-IP%.log" local6.* ?h3c #$template huawei,"/log_data/huawei/%FROMHOST-IP%.log" #local5.* ?huawei #$template cisco,"/log_data/cisco/%FROMHOST-IP%.log" #local4.* ?cisco 这里提供了三种品牌设备的日志收集方式，配置格式不是强制的。以 h3c 为例：第一行定义了一个h3c名字的模板，并且定义了保存的路径和文件名（以源ip命名），第二行定义收集 local6 类型的所有日志为应用到上面定义的 h3c 这个模板上。其中最关键的是这里 local6 要和网络设备中的配置一致即可。 至此重启 rsyslog 服务，在网络设备与日志服务器之间网络正常的情况下，即可在上面定义的目录中看到最新的日志

gitlab-runner/gitlab-ci的使用 0x1 优点 gitlab-runner、gitlab-ci能够主动触发任务。比如当某个分支的代码更新的时候自动触发任务，然后远程机器更新代码、编译，发布到站点。这样的话可以减少很多人工的资源更新站点。 0x2 安装部署 主要有以下步骤： 远程机器安装 gitlab-runner ，用于 gitlab 服务器指定分支提交任务后能够触发此机器 远程机器准备脚本，用于被调用后更新代码、编译、发布到站点，例如示例脚本： # 大概的步骤就是拉取指定分支代码、编译、发布到web服务器 #!/bin/bash # . /etc/profile . ~/.bash_profile set -x deploy_path="/data/www" if [ ! -d "/data/www/.git" ];then git clone git@gitlab.succez.com:product/www.git $deploy_path else cd $deploy_path git pull [ ! -d /data/www1 ] && mkdir -pv /data/www1 /usr/local/bin/npm run compile fi 在 gitlab 仓库中，代码目录下增加文件 .gitlab-ci.yml，内容示例如下: stages: - deploy deploy: stage: deploy script: - /home/gitlab-runner/bin/deploy_new only: - dev@product/www tags: - only_dev 具体参数的含义可以找到 gitlab-ci或者 gitlab-runner 文档查看，这里的意思大概是仅 dev 分支有更新才会出发编译，其他情况则不会 依次在此仓库中找到设置-> CI/CD -> Runner 找到注册地址和注册令牌，然后到远程机器上注册此仓库 到远程机器上执行命令 gitlab-runner register 然后根据提示注册到 gitlab 仓库上 回到 gitlab 仓库 runner 页面，即可看到注册上来的远程机器 gitlab-runner ，需要状态图片是绿色表示在线 至此，我们提交一个此分支的任务，即可在 CI/CD -> 流水线 中看到任务的执行了，后续也可以通过这里排查编译错误等