cgroup控制、限制那些资源
cgroup
cgroup（控制组）是Linux内核的一项特性，用于将进程组织成层次结构，并对这些进程进行资源限制、优先级控制、审计和监控。它能够控制和限制CPU时间、内存使用、磁盘I/O等资源的使用，以便更好地管理系统资源。
cgroup 主要有以下几种控制子系统（也叫cgroup controller）：
- cpu：控制进程的CPU使用，指定进程的CPU时间分配。可以限制进程占用的CPU核心数、CPU的优先级等。
- memory：限制进程的内存使用，包括物理内存和交换空间。可以指定最大内存使用量，避免进程内存占用过多导致系统崩溃。
- blkio：控制进程的磁盘I/O行为，限制读写操作的速率、优先级等。
- net_cls：用于网络流量控制，通过指定流量标识符（Class ID），限制或优先处理某些网络流量。
- devices：控制进程对设备的访问权限，可以限制某些设备的使用，确保进程不会对设备进行无关操作。
- freezer：可以冻结某个cgroup中的所有进程，暂停它们的执行，直到再次恢复。
- cpuset：指定进程运行的CPU核心和内存节点。可以将进程绑定到特定的CPU核心或内存节点，避免进程迁移。
- hugetlb：控制进程对大页内存（huge pages）的使用，可以限制进程申请大页内存的数量。
- pids：限制某个cgroup中可以创建的最大进程数，防止进程爆炸式增长。
- rdma：控制进程对RDMA设备的访问。
日常中遇到elk中性能问题
日常中遇到elk中性能问题
1.遇到过logstash写es提示429写尝试拒绝
- 1.后台es写压力大可以提升es thread_pool.write.queue_size/size大写（缓解）
- 2.es存储使用ssd，建议冷热分离，扩增数据存储节点(治本)
2.新增索引提示403（indice ready only）
- 1.临时关闭写保护，清理历史索引释放空间
- 2.调整es磁盘写保护阀值
- cluster.routing.allocation.disk.watermark.low，默认85%，用于控制磁盘的最小使用率；
- cluster.routing.allocation.disk.watermark.high，默认90%，用于控制磁盘的最大使用率；
- cluster.routing.allocation.disk.watermark.flood_stage，默认95%超过此值时，Elasticsearch变成只读模式，无法写入数据
3.logstash解析压力过大导致机器负载飙升，日志存在很大时延
- 1.kafka日志扩大分区，扩充logstash服务
- 2.改用gohangout解析，显著降低cpu/loadavg
4.提高可用性、增加redis/kafka作为日志缓冲组件
5.elasticsearch查询缓慢
- 合理设置分片，冷热区分，jvm堆内存预留50%，设置合理查询条件(防止全文查询)
6.kibana查询崩溃
- 设置nodejs内存(–max-old-space-size=4096)
kubernetes下 的kube-proxy挂了，有何影响
kube-proxy
Kubernetes中的kube-proxy是一个关键的网络组件，负责实现集群内部的服务发现和负载均衡。
kube-proxy 出现问题或停止工作影响如下
1.服务发现中断：
- kube-proxy 负责监听 Kubernetes API Server 中 service 和 endpoint 的变化情况，并通过代理的方式为服务配置负载均衡。如果 kube-proxy 停止工作，集群中的服务发现机制将无法正常运作，新的服务变化将无法被正确地传播和应用。
2.负载均衡失效：
- kube-proxy 通过为每个 Service 创建虚拟 IP 地址（VIP）和相应的网络代理规则，实现请求的负载均衡。如果 kube-proxy 出现问题，这些负载均衡规则将无法更新，导致流量无法正确地分发到后端的 Pod 上。
3.Pod间通信受阻：
- 在 Kubernetes 集群中，Pod 之间可以通过 Service 进行通信。如果 kube-proxy 故障，Pod 将无法通过 Service 访问其他 Pod 提供的服务，这将直接影响到依赖这些服务的应用程序的正常运行。
4.外部访问受限：
- 对于设置了NodePort的Service，kube-proxy 负责将从 NodePort 进入的请求转发到后端 Pod。如果 kube-proxy 出现问题，外部通过 NodePort 的访问请求将无法被正确转发，导致外部服务访问受限。
5.性能下降：
- kube-proxy 通过 iptables 或 ipvs 等机制来实现高效的网络流量转发。如果 kube-proxy 故障，可能会导致网络流量无法被高效处理，从而影响整个集群的性能。
linux上日志有那些？
1.系统日志(自检、启动、服务、授权、内核)
/var/log/message
- 事件日志
/var/log/auth.log
/var/log/secure
- 登陆、认证授权日志
/var/log/dmesg
- 启动硬件诊断、驱动日志
/var/log/kern.log
- 记录内核日志，比dmesg日志更加全面
/var/log/cron
- 执行计划日志
/var/log/btmp
- 失败登陆尝试日志
/var/log/wtmp
- 注销事件日志
/var/log/journal
- systemd管理服务日志
2.应用日志（一般都是有日志输出定义）
- 运行日志
- 错误日志
- 访问日志
- 埋点日志
3.crash 崩溃日志
- /var/crash/xxx kernel崩溃日志
- ～/core application崩溃日志
- ～/hs_err_pid
.log jvm崩溃日志
mysql GTID复制机制
MySQL 的 GTID（Global Transaction Identifier，全局事务标识符）复制机制是 MySQL 5.6 及以上版本引入的一种高级复制功能，旨在简化主从复制的管理，提高数据一致性和故障恢复的可靠性。相比传统的基于二进制日志位置（binlog position）的复制方式，GTID 复制通过为每个事务分配一个全局唯一标识符，极大地方便了复制的配置和维护。
GTID 复制的基本原理
GTID 是一个全局唯一的事务 ID，由两部分组成：
- 服务器 UUID：每个 MySQL 实例有一个唯一的标识符，通常在服务器启动时生成，存储在
auto.cnf文件中。 - 事务序列号：一个递增的数字，表示该服务器上的事务顺序。