去哪儿网也在很多场景依赖Zookeeper,所以我们也一直在摸索怎么更好的运维稳定的Zookeeper集群。在过去的几年我们也踩过一些坑,也因为Zookeeper导致了故障。 现在将我们运维Zookeeper集群的一些经验分享,也欢迎大家提供更好的建议。 那么在打算运维一套Zookeeper集群之前,我们先了解一些Zookeeper的基本原理。 网络流量以及client ip 这个会记录到监控系统里,这样很快能发现『害群之马』 10. 一些使用建议 a. 不要强依赖Zookeeper,也就是Zookeeper出现问题业务已然可以正常运行。
常态下该值应该持续为0,不应该有未处理请求 zk_pending_syncs 说明:常态下该值应该持续为0,不应该有未同步的数据 zk_znode_count 说明:节点数越多,集群的压力越大,性能会随之急剧下降 经验值 需要考虑以机房/地域/业务等维度进行拆分 zk_approximate_data_size 说明:当快照体积过大时,ZK的节点重启后,会因为在initLimit的时间内同步不完整个快照而无法加入集群 经验值 尝试操作 创建/删除/读取节点 说明:在/zookeeper_monitor节点下,定期创建/删除节点,确保该功能可用 建议:创建/zookeeper_monitor节点,不要使用业务节点,避免互相影响 经验值 在弹出的界面选择“远程进程”,输入“服务器IP:9991”(zookeeper服务器的IP和端口) 实践经验 分Group 要确保Zookeeper整个集群可靠运行,就是要确保投票集群可靠。
背景介绍: 从事日志系统的开发运维1年多了,Kafka集群一直是系统中最重要的集群之一。及时有效地处理Kafka问题,是保障系统运行稳定的重要工作。 这时需要提前在每个时间点记录当前partition的offset,在Kafka集群中可以考虑每隔10分钟记录一次offset,在数据回放时,按照时间和offset数据,直接读取Topic中数据进行处理。 (二)Kafka监控 image.png 在运维kafka系统的过程中,我们根据业务的特点,为了能及时发现上述问题,对所有的集群进行了如下方面的监控: 1,生产者offset变化监控(partition
(发布变更、监控处理、数值调整、数据提取等)的无人值守服务,而且还给运维人员提供了解决方案(工具),并随时调整,避免重复性的操作服务。 其实做运维练就的是一种心态,足够淡定遇事而不乱,从容应对才是真。 排查出问题并找到根本原因加以解决,个人认为是一件很成就感的事情。曾经有人问过我:“你是怎么想到问题出现在xxx的? 八、总结记录,破案归档 好记性不如烂笔头,然而在一片混乱问题分析当中,让运维心平气和地记录下问题与判断确实有点不切实际。 运维专家或许是每个运维人追寻的梦想,他们敏锐的嗅觉似乎总能揪出系统故障的根本原因。这种快速反应、准确定位的能力源自多年来处理复杂系统难题的经验积累与个人知识储备,而且其成功很难被复制。 文中涉及的方法、经验和思想不代表最佳实践。 --- 蓝鲸智云简介 腾讯蓝鲸智云(简称蓝鲸)软件体系是一套基于PaaS的技术解决方案,致力于打造行业领先的一站式自动化运维平台。
导语:运维可以说是世界上最紧张且强度最大的工作之一,每个杂乱无章的问题背后都需要我们的深入的抽丝剥茧。尤其是当你面对的问题直接与收入业务、海量服务运营挂钩时,可谓是肾上腺素瞬间飙升。 其实做运维练就的是一种心态,足够淡定遇事不乱,从容应对才是真。 从入行到现在,遇到过各式各样千奇百怪的问题,每个业务形态和系统均不一样,排查出问题并找到根本原因加以解决,其实是一件很成就感的事情。 排查问题犹如破案 运维排查线上问题犹如警察破案一样,是一个不停分析线索,推理的过程,但在准备排查问题之前,我们应该明白三个认知:认知,几乎是人和人之间唯一的本质差别。 卷宗记录,破案归档 好记性不如烂笔头,然而在一片混乱问题分析当中,让运维心平气和地记录下问题与判断确实有点不切实际。 结语 运维专家或许是每个运维人追寻的梦想,他们敏锐的嗅觉似乎总能揪出系统故障的根本原因。这种快速反应、准确定位的能力源自多年来处理复杂系统难题的经验积累与个人知识储备,而且其成功很难被复制。
// MongoDB运维与开发(10)---chunk // MongoDB中,在使用到分片的时候,常常会用到chunk的概念,chunk是指一个集合数据中的子集,也可以简单理解成一个数据块,每个
第10章 Spring Boot应用部署运维 10.1 Spring Boot应用运行 To create a ‘fully executable’ jar with Maven use the following
环境准备 实验机器环境(虚拟机):Linux ky10.x86_64 、Linux CentOS 7.6_x86_64 其中本次实践演示为CentOS 7.6虚拟机。 结束 扇区, +扇区 or +size{K,M,G} (2048-41943039,默认为 41943039):# 第五步 结束大小,使用默认,直接回车 分区 1 已设置为 Linux 类型,大小设为 10
前九期我们从IT资产管理、监控、U 位管理、自动化方案到运维知识库,搭建起了精细化运维的 “工具库” 和 “经验库”。 运维服务台正是为此而生 —— 它是运维工作的 “总调度中心”,不管是普通运维人员查设备、报故障、跟踪进度,还是管理员派工单、管流程、做复盘,都能一站式完成。 先分清:运维服务台 vs 运维知识库,相辅相成不混淆很多人会把服务台和第九期的知识库搞混,其实两者各司其职、相辅相成,用一句话就能分清:· 运维知识库:核心是 “查答案”,是 “运维经验库”,比如遇到 核心功能与价值:闭环、高效、可追溯,一站式解决运维痛点运维服务台的核心价值,是串联前九期的所有运维成果,解决 “多工具切换、故障无跟踪、流程不规范” 的痛点,核心功能和价值如下:✅一、核心功能:覆盖运维全流程 运维服务台让所有工具、流程、经验形成闭环,让运维工作不用切换工具、不用多渠道沟通,真正实现 “高效、规范、可追溯”。
开发挖坑,运维埋! 运维如庖丁解牛,得意处游刃有余,碰壁时寸步难进。 在天愿作比翼鸟,在地愿结运维亲,第一个为你排忧解难的不是老公而是默默的运维人! 运维是城管,维持秩序的是它,背锅的也是它;运维是对应用的承诺,不离不弃一辈子;运维是血与泪——发生在夜深人静的时候。 运维是块砖,哪里用哪里搬。不出问题你打杂,出了问题你负责。 天下运维是一家,一入运维深似海! 运维就是7*24 别惹运维,否则后悔! 运维其实很简单“三分技术、七分管理“。 我们真的不只是会重启,我们还会背锅啊。 好的运维不需要经常加班。 做的好的是运维,没做好的是背锅侠。 运维让产品更出色,让技术更有价值! 规范流程,临危不惧,提供值得信赖的运维服务。 运筹维幄,百味人生。 运维就是我每天念想的但又触及不到的梦想。 不为人知的幕后英雄 运维就是不断的重启、重启、再重启。 运维的本质是”可控” 运维人,做的多,说得少。 运维是救火员,平时用不到,出事少不了。
环境准备 实验机器环境(虚拟机):Linux ky10.x86_64 、Linux CentOS 7.6_x86_64 其中本次实践演示为CentOS 7.6虚拟机。 所以,我们需要额外的命令工具来做支撑,实验之前,先检查下机器已经挂载的磁盘,可使用lsblk命令来查询,如果不了解这个命令,可以参考博主以前的博文:Linux工具|运维工具lsblk使用小妙招 注意:Linux 结束 扇区, +扇区 or +size{K,M,G} (2048-41943039,默认为 41943039):# 第五步 结束大小,使用默认,直接回车 分区 1 已设置为 Linux 类型,大小设为 10
并发netstat -na | grep ESTABLIS | wc -l tcp数netstat -an|grep ":80 "|grep -v grep|wc -l # 10.说说tcp/ip的七层模型
技术分享三条实战经验: ● 良好的逻辑性 ● 自己真实经验总结 ● 多练习 首先,说明下,我不是技术分享高手,分享了次数比较多,有点心得;另外,听的分享多了,对好坏也有一些感受。 还有,在此特别感谢下西山居的运维开发架构师,《Puppet实战》的作者刘宇,我的许多分享经验来自于宇哥,并且得到了宇哥多次的,一对一贴身的,手把手的指点。 二 如何做好技术分享 1.做好功课,了解听众 运维分享通常是思路、方法、及在某些方面的技术实践,因为需要背景知识,不是所有人都能听懂,所以了解自己的听众非常重要,比如对于刚入行的朋友和资深的从业者,内容和深度就应该不一样 树形 从根部开始,分模块介绍,比如私有云的运维,按照计算、存储、网络、管理等模块,逐个介绍。使用这个方案,建议画一个脑图。 1.挑战自我 一次分享,台上40-60分钟,台下需要10倍的时间准备,整个过程是对自己知识体系的整理和再完善。
四、故障自愈的防御体系在构建智能运维系统时,我们提炼出"故障三态模型":瞬时故障(如网络抖动)、间歇故障(如磁盘坏道)、持久故障(如节点宕机)。 运维启示录:集群的稳定性不在于处理故障的能力,而在于预见故障的智慧。 操作系统调优需把握三个黄金参数:vm.swappiness=10防止内存抖动、net.core.somaxconn=1024提升网络连接能力、deadline调度器替代cfq降低IO延迟。 八、智能运维的未来图景在某智慧城市的超大规模集群中,我们构建了AI运维中台:通过LSTM模型预测集群负载,结合强化学习进行参数调优推荐。系统每日处理2TB运维数据,自动生成《健康度诊断报告》。 让技术经验流动起来 ▌▍▎▏ 你的每个互动都在为技术社区蓄能 ▏▎▍▌ ✅ 点赞 → 让优质经验被更多人看见 收藏 → 构建你的专属知识库 转发 → 与技术伙伴共享避坑指南 点赞 ➕ 收藏
嘉宾介绍 朱文潇 ,大型互联网公司 8 年 Redis 运维实战经验,多次以核心身份主导 Redis 框架方案设计及落地实施,对 Redis 服务有深刻理解,对多种 Redis 实现方案都有独到的见解。 3)Codis 集群高可用方案:一款分布式缓存高可用集群产品,提供了配套的客户端,提供了动态数据迁移,内置高可用方案,产品设计解决了运维大部分痛点;同样,如果想阅读更多关于 Codis 的内容,可以点击我之前出的一篇文章 从 Redis 2.X 到 Redis 3.X 以上版本需要投入很多测试,整体的运维技术也有很大的变化,需要不断的研究、不断的学习,这也是对运维人员的考验。 4 所维护的集群最大 QPS 是多少? 1)Redis 源代码并不长,有能力的一定要好好欣赏一下作者的代码艺术; 2)付磊、张益军两位老师编写的《Redis 开发与运维》,有原理解读,有实战经验,值得一看; 3)Redis 社区活跃度比较高, 相关阅读 《用实战经验浅谈 Redis 核心技术》 第01期:你好!
冷菠 冷菠,资深DBA,著有《Oracle高性能自动化运维》,有近10年的数据库运维、团队管理以及培训经验。擅长数据库备份恢复、数据库性能诊断优化以及数据库自动化运维等。
春节对咱们运维人来说,从来不是单纯的假期,而是一场“保稳定”的硬仗。 下面结合我这些年的一线实操经验,拆解各核心组件的巡检要点和常用命令,都是实打实能用得上的干货。 若出现连接异常,用tcpdump -i eth0 port 2049 -c 10抓包测试NFS端口(2049)通信,排查网络层面阻塞;同时翻一翻/var/log/messages日志,里面会记录NFS连接 链路连通性:丢包、延迟早排查ping 目标IP -c 10测试连通性,丢包率必须低于1%,延迟也要在合理范围,跨地域链路可稍微放宽要求。
堡垒机 有时候也叫运维审计系统,可以配合 Windows 域或其他认证系统,对运维人员的操作进行审计。网络的访问控制做的好的话,个人认为堡垒机是安全运维里面最有用的设备之一。 从工作职责说明上写清楚安全运维人员的职责和绩效评估方法,因为安全设备的运维都属于日常性的工作,可以做工作计划,按照计划推动安全设备的日常运维工作。 结合运维、开发部门流程将与安全流程整合到一起。 如果运维部门有类似的系统,放在一起做。设备少的情况下也可以手工记录。 定期对业务网络环境做漏洞扫描,跟业务部门、开发部门、运维部门确认漏洞修复状态,不能修复的说明情况,采取补偿的方式对有漏洞系统进行防护。
文章目录如下,是笔者过去5年作为乙方在多个银行设计和落地应用运维自动化的经验分享,共11000字,阅读时长大约10分钟。 2018年10月,中国银行保险监督管理委员会发布《中国普惠金融发展情况报告》摘编版,中国财政也加大了普惠金融发展专项资金的投放。 运维工作如此繁重,运维人员在横向扩展自己运维技能的同时,还有时间往运维开发、大数据或AI等纵向技术领域转型吗? 03 应用灾备演练 在过往10年,大多数银行致力于“两地三中心”的灾备建设,到目前,基本都已经实现了核心系统的灾备建设。灾备建设的根本目的在于出现不可预知灾难时的应急切换,以快速恢复业务。 对应用各模块、各主机进程的启停提供编排能力,实现应用的一键启停 10 应用自动化运维关键能力一览 ? 11 其他 本文先聚焦于银行应用运维的关键场景和相应产品能力。
用户模块可以帮助用户管理远程客户机中的用户,例如创建、删除、修改用户属性等。其常用的参数如表1.5所示。