TCPDUMP

作者：xuty 本文来源：原创投稿 *爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。 一、概述 之前在社区发了一篇 故障分析 | 有效解决 MySQL 行锁等待超时问题 文档，主要介绍了下行锁超时的监控方法，下方评论中有人提到了 pt-stalk 工具也可以监控行锁超时，因为个人没怎么用过这个工具，所以下意识的就去 google 了一下。因为没找到有介绍具体监控输出的文档，就以为这个工具没法监控行锁等待，最后果断被打脸了。 以上是个小插曲，个人在本地测试了下 pt-stalk 的监控输出后，发现其监控项远远比我预测的多，用起来也比较方便，所以在这里分享下这个工具。 二、介绍 首先介绍下 pt-stalk ，它是 Percona-Toolkit 工具包中的一个工具，说起 PT 工具包大家都不陌生，平时常用的 pt-query-digest 、 pt-online-schema-change 等工具都是出自于这个工具包，这里就不多介绍了。 pt-stalk 的主要功能是 在出现问题时收集 OS 及 MySQL 的诊断信息 ，这其中包括： OS 层面的 CPU、IO、内存、磁盘、网络等信息； MySQL 层面的行锁等待、会话连接、主从复制，状态参数等信息。 而且 pt-stalk 是一个 Shell 脚本 ，对于我这种看不懂 perl 的人来说比较友好

GOREPLAY是一个网络流量转发的应用，之前的名字叫GOR，GITHUB上的作者有介绍，更准确说应该是HTTP流量转发，作者的目标应该是WEB型应用在内网的转发，因为HTTP是一个应用广泛的协议，并且是标准的，因此从这个角度出发编写出来的转发应用能够在绝大多数的场景使用。这也会带来一定的问题，假设我们要转发其他的协议类型，这个时候需要自行编码识别协议的边界再做转发。 GOREPLAY使用GO语言编写，使用了一系列GO的工具，如操作pcap、kafka等。运行goreplay的前提也需要安装pcap等工具，并且需要在root权限下才能打开网卡的混杂模式，监听指定端口的所有tcp报文。GOREPLAY的工作流程： 1.使用pcap的go接口，使用bpf（伯克利包过滤）设置指定端口的过滤表达式，bpf可以参考tcpdump工具的表达式，tcpdump命令背后也是使用了bpf。 2.截取到tcp报文之后，根据网络五元组（又一个名词，<源IP，源端口，目标IP，目标端口，协议>，实际程序中没有使用协议这个字段）作为key露拼装message，因为HTTP基于TCP协议，根据TCP协议中的ACK以及SEQ识别一次调用包的完整性。想读懂代码需要对TCP协议报文格式，HTTP协议格式有一定的了解，除了普通HTTP协议报文，还需要了解CHUNKED等比较少见的报文。 3

　　线上故障主要会包括cpu、磁盘、内存以及网络问题，大多数故障可能会包含不止一个层面的问题，进行排查时候尽量四个方面依次排查一遍。例如 jstack、jmap 等工具，出问题就是df、free、top 三连，然后依次jstack、jmap，具体问题具体分析。 CPU: 　　一般来讲我们首先会排查 CPU 方面的问题。CPU 异常往往还是比较好定位的。原因包括业务逻辑问题(死循环)、频繁gc以及上下文切换过多。而最常见的往往是业务逻辑(或者框架逻辑)导致的，可以使用jstack来分析对应的堆栈情况。 　　使用 jstack 分析 CPU 问题 　　我们先用 ps 命令找到对应进程的pid(如果你有好几个目标进程，可以先用top看一下哪个占用比较高)。接着用 top -H -p pid 来找到 CPU 使用率比较高的一些线程 　　　　　　 　　然后将占用最高的 pid 转换为 16 进制 printf '%x\n' pid 得到 nid 　　接着直接在 jstack 中找到相应的堆栈信息 jstack pid |grep 'nid' -C5 –color 　　　　　　 　　可以看到我们已经找到了 nid 为 0x42 的堆栈信息，接着只要仔细分析一番即可。 　　当然更常见的是我们对整个 jstack 文件进行分析，通常我们会比较关注 WAITING 和 TIMED_WAITING

软件工程领域存在一个共识：维护代码所花费的时间要远多于写代码。而整个代码维护过程中，最惊心动魄与扣人心弦的部分，莫过于问题排查（Trouble-shooting）了。特别是那些需要 7x24 小时不间断维护在线业务的一线服务端程序员们，大大小小的问题排查线上救火早已成为家常便饭，一不小心可能就吃成了自助餐 —— 竖着进躺着出，吃不了也兜不住。 本文分享作者在服务端问题排查方面的一些经验，包括常见问题、排查流程、排查工具，结合实际项目中发生过的惨痛案例进行现身说法。 一 、问题排查 1、常见问题 Know Your Enemy：知己知彼，百战不殆。 日常遇到的大部分问题，大致可以归到如下几类： 逻辑缺陷：e.g. NPE、死循环、边界情况未覆盖。 性能瓶颈：e.g. 接口 RT 陡增、吞吐率上不去。 内存异常：e.g. GC 卡顿、频繁 FGC、内存泄露、OOM。 并发/分布式：e.g. 存在竞争条件、时钟不同步。 数据问题：e.g. 出现脏数据、序列化失败。 安全问题：e.g. DDoS 攻击、数据泄露。 环境故障：e.g. 宿主机宕机、网络不通、丢包。 操作失误：e.g. 配置推错、删库跑路（危险动作，请勿尝试..）。 上述分类可能不太完备和严谨，想传达的点是：你也可以积累一个这样的 checklist，当遇到问题百思不得其解时，耐心过一遍，也许很快就能对号入座。 2、排查流程

前言 日志是MySQL数据库的重要组成部分。日志文件中记录着MySQL数据库运行期间发生的变化；也就是说用来记录MySQL数据库的客户端连接状况、SQL语句的执行情况和错误信息等。当数据库遭到意外的损坏时，可以通过日志查看文件出错的原因，并且可以通过日志文件进行数据恢复。 MySQL的日志体系有如下几种分类： 错误日志 查询日志 慢查询日志 事务日志(Redo log) 二进制日志 中继日志 其中标粗的事务日志和二进制日志，是重中之重。 1 错误日志 在默认情况下，MySQL的错误日志是开启的，且无法被禁止。在没有指定的情况下，它一般是存储在数据库的数据文件目录中，名称为hostname.err，其中，hostname为服务器主机名。 1.1 错误日志的内容 服务器启动和关闭过程中的信息，未必是错误信息，比如mysql是如何去初始化存储引擎的过程记录在错误日志里等等 服务器运行过程中的错误信息（或者告警信息），比如sock文件找不到，无法加载mysql数据库的数据文件，如果忘记初始化mysql或data dir路径找不到，或权限不正确等 都会记录在此 事件调度器运行一个事件时产生的信息，一旦mysql调度启动一个计划任务（event scheduler）的时候，它也会将相关信息记录在错误日志中 在从服务器上启动从服务器进程时产生的信息，在复制环境下

# 先进到/tmp 目录执行，方便Filezila 传输 # 开启抓包 nohup tcpdump -i eth0 -s0 -nnA 'port 22' -w dump22.pcap & [1] 15022 # 查询pid ps -ef|grep tcpdump |grep -v 'grep' # 结束抓包 kill 15022 参考 https://www.cnblogs.com/bonelee/p/6121821.html 来源： oschina 链接： https://my.oschina.net/u/4402117/blog/4277973

由于操作系统自带的软件的版本过低，可能出现版本漏洞，被***利用来远程操控系统，所以需要定期更新自己的操作系统的版本，下面是整理的一些centos7.6上面可以存在漏洞的版本，建议尽快升级 软件： elfutils-default-yama-scope 0.172-2.el7 命中： elfutils-default-yama-scope version less than 0:0.176-2.el7 路径： /usr/lib/sysctl.d/10-default-yama-scope.conf 软件： elfutils-libs 0.172-2.el7 命中： elfutils-libs version less than 0:0.176-2.el7 路径： /usr/lib64/elfutils 软件： elfutils-libelf 0.172-2.el7 命中： elfutils-libelf version less than 0:0.176-2.el7 路径： /usr/lib64/libelf-0.172.so 解决： yum update elfutils* -y 软件： bind-license 9.9.4-74.el7_6.1 命中： bind-license version less than 32:9.11.4-9.P2.el7 路径： /usr

一、 集群分类： Ø HA Cluster ： High Availability Cluster ，高可用集群。运行于两个或多个节点上，当应用程序出现故障，或系统硬件、网络出现故障时，应用程序可以自动、快速地从一个节点切换到另一个节点，最大限度地减少服务中断时间，从而保证应用程序持续、不间断地对外提供服务。对于此类集群还有很多通俗的名称，如“双机热备”、“双机互备”等。 Ø LB Cluster ： Load Balance Cluster ，负载均衡集群。运行于两个或多个节点上，客户端的请求按照不同的算法分配给后端服务器，以减轻服务器的压力，降低对服务器的硬件和软件要求，适用于大负载访问量的服务，如 Web 服务。负载均衡集群可以通过软件方式实现，也可以通过硬件设备来实现。 Ø HPC Cluster ： High Performance Computing Cluster ，高性能计算集群。提供单个计算机所不能提供的强大计算能力，包括数值计算和数据处理，并且倾向于追求综合性能。 二、 Keepalived 简介： Keepalived 是 VRRP 协议的软件实现，原生设计是为了高可用 IPVS 服务，可以实现如下功能： Ø 基于 VRRP 协议完成地址流动 Ø 为 VIP 地址所在的 IPVS 集群节点生成 IPVS 规则（在配置文件中预先定义） Ø 为 IPVS 集群的各

libpcap是一个网络数据包捕获函数库，功能非常强大，Linux下著名的 tcpdump 就是以它为基础的。今天我们利用它来完成一个我们自己的网络嗅探器(sniffer) 首先先介绍一下本次实验的环境： Ubuntu 11.04，IP：192.168.1.1，广播地址：192.168.1.255，子网掩码：255.255.255.0 可以使用下面的命令设置： sudo ifconfig eth0 192.168.1.1 broadcast 192.168.1.255 netmask 255.255.255.0 1.安装 在 http://www.tcpdump.org/ 下载libpcap（tcpdump的源码也可以从这个网站下载） 解压 ./configure make sudo make install 2.使用 安装好libpcap后，我们要使用它啦，先写一个简单的程序，并介绍如何使用libpcap库编译它： Makefile： all : test.c gcc -g -Wall -o test test.c -lpcap clean : rm -rf *.o test 其后的程序的Makefile均类似，故不再重复 test1.c #include <pcap.h> #include <stdio.h> int main() { char errBuf[PCAP

声明： 本文是我在工作中遇到的一种apk使用本地代理接收媒体流的方式，这种方式可以更加的安全。这里与大家分享，希望可以对你有所帮助。 介绍： 1.某apk获得数据和向player发送数据的方式： a. 使用本地代理的方式访问服务器，而本地代理就是使用 127.0.0.1 的网址。某apk首先会通过本地代理向服务器发送对应视频的请求，只不过这里发送请求的URL中加入了Accept-Encoding：gzip\r\n 关键字，这个关键字就是向服务器申明自己是可以接收加密数据的。而如果服务器有加密数据将返回客户端加密的数据，同时会在返回客户端的请求中加入 Content-Encoding: gzip：表明传输的数据是gzip过的数据，而 Content-Length:117：表示gzip压缩后的数据大小，便于客户端使用。 b. 本地代理获得数据后会检测响应中是不是有 Content-Encoding: gzip，如果有，之后会对数据解码。并将解码后的清流推送到播放器进行播放。 而关于HTTP gzip可以看下面的介绍： https://www.jianshu.com/p/b0a463958b60 https://blog.csdn.net/u010266010/article/details/80331889 2. 而通常我们是不能抓到本地（127.0.0.1）的网络包的