笔者在转转主要负责环境治理相关的工作，本篇主要和大家分享，测试环境问题排查的一些经验。
近日在某客户现场进行巡检，发现有一个系统在进行sqlplus / as sysdba登录的时候特别缓慢。多次测试，最长时间可以达到近10s才能成功登录。此时，对主机的CPU、内存、IO以及网络等参数进行查看，发现使用率均不高，远远没有达到瓶颈，且在登录之前和登录之后，所有操作均非常顺滑，没有任何卡顿。因此，判断该系统就是在sqlplus登录的时候才可能出现卡顿。
无论是 CPU 使用率，还是平均负载，都只是反映系统健康状态的度量指标，而不是问题的根因;
虽然今天处置的时候并非本文章情况，等过段时间结束了我在发一下我的处置过程涉及到的技术点以及思路
基于公司发展硬性需求，生产VM服务器要统一迁移到ZStack 虚拟化服务器。检查自己项目使用的服务器，其中zookeeper集群中招，所以需要进行迁移。
本文为整个专题的第四篇，中间跳过了原计划的“内网横向移动攻击模拟（下）”。原因是下与上的类型一致，均为攻击模拟的记录，可分享和讨论的意义不大，只要按照这种模式可以设计出更多的场景。继而，继续编写本专题后续的内容。
由于业务应用 bug(本身或引入第三方库)、环境原因、硬件问题等原因，线上服务出现故障 / 问题几乎不可避免。例如，常见的现象包括请求超时、用户明显感受到系统发生卡顿等等。
运行上面命令，其实是service命令去找/etc/init.d下的相关的mysql脚本去执行启动、关闭动作。
首先通过我们内部搭建的日志平台发现我们线上环境一个java应用有大量的http接口请求超时，登录linux服务器查看网络环境没有问题，判断是应用自身运行异常，重启应用后发现异常还在，开始查找问题。
在日常繁琐的运维工作中，对linux服务器进行安全检查是一个非常重要的环节。今天，分享一下如何检查linux系统是否遭受了入侵？ 一、是否入侵检查 1）检查系统日志 检查系统错误登陆日志，统计IP重试次数（last命令是查看系统登陆日志，比如系统被reboot或登陆情况） [root@bastion-IDC ~]# last 2）检查系统用户 查看是否有异常的系统用户 [root@bastion-IDC ~]# cat /etc/passwd 查看是否产生了新用户，UID和GID为0的用户 [root@b
好久不见，我是Mars先生小量子！今天MINMIN有空手道训练，来不及写本周的推送了，只能由我救急了~正好最近处理了好几个客户报的bug，搞得我焦头烂额，乘此机会分享一下trouble shooting的经历。
为了跟踪和发现在Kubernetes集群中运行的容器应用出现的问题，常用如下查错方法：
发生故障后，不要只顾闷头排查问题，还要及时向你的直属领导汇报故障现象、影响范围、修复措施和修复进度，如果可以，最好再汇报一个大概的恢复时间。这不是浪费时间，而是让你的领导快速了解故障情况，评估风险，以便于协调内外部资源，同时争取更多的决策时间应对老板或业务部门的催促。如果是等级较高的故障就需要联系该系统相关人员一起排查，同时与该业务线的前后端开发、测试、运维及 DBA，多线程并行作战。在清楚故障现象后，各自排查自己负责的模块，最大限度地动用可利用的资源。严重的线上故障一定是要协调各方资源一起排查，因为只有掌握了足够多的信息，才能做出解决问题的正确决策。有必要的情况下，对故障升级要求更多的人投入进来解决该问题
最烦的事情，莫过于服务莫名其妙的重启，当你看到一个服务一天重启23次，你会是怎样的一个感觉，反正博主我快要摔电脑了。。。。
Linux 内核有个机制叫OOM killer（Out-Of-Memory killer），该机制会监控那些占用内存过大，尤其是瞬间很快消耗大量内存的进程，为了防止内存耗尽而内核会把该进程杀掉。
最近技术群里面有几个同学碰到了 删除Topic的问题, 怎么样也删除不掉,然后我协助排查之后,就做个记录,写篇文章,大家在碰到这类型的问题的时候应该怎么去排查
1、背景 由于Oracle对外宣称Oracle JDK停止免费用于商用。公司法务部门评估之后担心后续会惹上光司，于是就开始了JDK升级-将所有服务Oracle修改为OpenJDK。上周开始微服务JD
回望整个过年期间真的是躺的平平的，每天学习的时间和平时比起来差的不是一星半点。今天就复工了，也要收心了。我这个人有一个比较牛逼的能力就是状态调整特别快，只需要往工位上一坐下，我就能进入复工状态了。
一日凌晨，手机疯狂报警，短信以摧枯拉朽之势瞬间以百条的速度到达，我在睡梦中被惊醒，看到短信的部分内容如下：
今天和同事一起处理了一个奇怪的MySQL空间异常问题，从这个问题的处理中可以找到一些问题处理的方式。
当问起凤梨叔 两年前全网热议的 DNSPod解析遭到攻击的那天。 关于当晚的每一个的细节，他依旧了然于心。 将时间线拉回到2018年11月9号当晚 当收到告警时， 出现在凤梨叔的脑海里的第一个念头是： 坏了，被攻击了！ 凤梨叔第一件做的不是去排查问题 而是先手动重启B地的部分DNS服务器 多年的从业经验告诉他 外部攻击很多时候是分地域的 不同地区受影响可能不同 A地的服务器启动异常不表示其他地区会马上异常 这个决定 能在保证服务持续提供的同时 也留出找到原因的时间 同时 凤梨叔立即联系腾讯
EasyCVR视频融合平台基于云边端一体化架构，具有强大的数据接入、处理及分发能力，平台支持海量视频汇聚管理，能在复杂的网络环境中，将分散的各类视频资源进行统一汇聚、整合、集中管理，实现视频直播、云端录像、云存储、检索回看、智能告警、平台级联、服务器集群、云台控制与语音对讲、电子地图、轨迹跟踪等功能。
说明:百度的应急文章很多，在此不在介绍如何按照手册进行排查，只针对实战进行分析和排查。
题记：在RAC数据库的故障当中，节点重启的现象很常见，在这种问题的处理当中，有一定的规律性。为了更好的说明这个问题的处理过程，保证出现该类问题的时候，能够有序的进行处理，特编写此文档。
说起来日常的故障，其实，首先应该相到的就是：“备份”、“备份”、“备份”。毕竟再怎么牢固的系统或硬件都会有故障的时候，所以，备份放第一位。
前段时间用户反馈某生产环境 TiDB 集群 drainer 频繁发生故障，要么服务崩溃无法启动，要么数据跑着跑着就丢失了，很是折磨人。该集群跑的是离线分析业务，数据量20T ，v4版本，有多个 drainer 往下游同步数据，目标端包括kafka、file、tidb多种形态。
1. 什么是linux服务器load average？ Load是用来度量服务器工作量的大小，即计算机cpu任务执行队列的长度，值越大，表明包括正在运行和待运行的进程数越多。 参考资料：http://en.wikipedia.org/wiki/Load_average
我们线上有一个服务，姑且称之为A服务，它会请求其他部门的B服务获取必要的数据，因此这个链路是关键链路，不容有失。但因为跨部门，我们两个团队的技术栈不同，使用的RPC框架也不同，通信协议的格式也不同，且不是通用协议，双方的内部库也不一样。因此对方部门提供了一个SDK，让我们作为调用B服务的client集成到A服务中。该SDK除了协议的序列化和反序列化的功能外，也包含寻址以及负载均衡的逻辑。
值此七夕佳节，烟哥放弃了无数妹纸的邀约，坐在电脑面前码字，就是为了给读者带来新的知识，这是一件伟大的事业！ 好吧，实际情况是没人约。为了化解尴尬，我决定卖力写文章，嗯，一定是我过于屌丝！ 好了，开始说重点。今天讲的这个问题
最终结果是三分之一的直播录制视频完全丢失，其它的录制视频都是不完整，也就是说只录制了前半部分，后半部分是没有的。
下面我们看一个标准的服务器安全应急影响应该怎么做，也算是笔者从事安全事件应急近5年以来的一些经验之谈，借此抛砖引玉，希望大神们不吝赐教。
本文记录了本人遇到的几个电脑硬件问题，以及尝试解决的过程。最终问题都算是解决了，不过也都算是瞎猫碰到死耗子吧，就当作给大家提供点思路吧。抛砖引玉，希望大家也能分享一些自己的案例。
项目的登录接口 /User/loginPage 从凌晨4点到下午1点一直有5k QPS的流量在压，询问了所有的压测团队，并没有在进行压测。这么大的流量影响到了现网环境，需要立刻找到原因，关闭掉异常流量。
情况是这样的，有一套测试数据库所在的主机在最近几个月，每个月都会重启一至两次，由于数据库配置了开机自启动，且每次重启时间都比较短暂，便没有得到重视。最近由于测试人员的反馈，每当主机重启后呢会导致大片的测试应用由于断连导致无法使用，每次都需要重启应用才会好。那么我们就需要介入认真排查一下问题所在了，恰巧最近一次的重启时间为 11 月 10 日 18:29 左右，需要针对此问题分析 os 重启原因。
打开 Default Value 可以和 代码中设置 ini_set('display_errors','On');起到同样的效果
不小心重启了线上服务器的网卡，结果整个网络不通了，就算使用127.0.0.1访问都不行，第一次遇到这种问题，当时就六神无主了，两个人排查了好久也没找到原因，万分火急。排查内核日志发现网卡状态不断地从Not Ready到Ready切换，但是却看不出任何原因。没办法还是得从日志中找原因，由于不知道错误关键词，只能肉眼盯着滚动的系统实时日志，终于功夫不负有心人，看到了这行日志：IPV4 forwarding is disabled. Networking will not work，下面就将整个排查过程简单明了的说明一下，希望能帮助到大家。
java TestLinuxDemo
因为重启已经看到mount挂载时失败了，使用 mount -a 重启挂载，结果挂载失败了
《研发日记》这个系列的诞生初衷，是希望分享 AutoMQ 版本迭代中我们的研发故事，其中会包括技术调研、问题诊断、性能优化等内容。如果你也对 AutoMQ 背后的技术和进展感兴趣的话，欢迎关注我们。
就绪探针，用来判断 pod 是否就绪，就绪状态时service才会分发流量给该pod。
本文将引入一个思路：“在 Kubernetes 集群发生网络异常时如何排查”。文章将引入 Kubernetes 集群中网络排查的思路，包含网络异常模型，常用工具，并且提出一些案例以供学习。
Yaf框架是一个c语言编写的PHP框架，它更快、更轻、内存占用更低。项目组本着对性能的追求选择了Yaf框架，由于安全的原因PHP升级到7.3.18，为了兼容PHP，将Yaf升级到3.2.3。Yaf框架的bug导致PHP进程core。尽管从表象上看就是一个core，但整个排查解决的过程还是遇到了不少困难，这里记录了这一次线上core的整个排查过程，希望能够帮助遇到类似问题的同学。
在Linux操作系统中，每个运行的进程都有一个唯一的标识符，即进程识别号（PID）。了解进程识别号对于系统管理和故障排查是至关重要的。本文将深入探讨如何查看Linux中的进程识别号，以及了解PID在系统运行中的作用。
1、在EMR控制台首页，选择“集群服务>HDFS>角色管理”，尝试重启该namenode进程。
流计算作业通常运行时间长，数据吞吐量大，且对时延较为敏感。但实际运行中，Flink 作业可能因为各种原因出现吞吐量抖动、延迟高、快照失败等突发情况，甚至发生崩溃和重启，影响输出数据的质量，甚至会导致线上业务中断，造成报表断崖、监控断点、数据错乱等严重后果。
昨天一个前同事找我，问有没有性能测试岗位的面试题，正好之前帮业务团队加面过几次性能测试岗位的候选人，我将面试时候会问的一些问题以及要考察的点列了出来，供大家参考。
近日，腾讯云安全团队监测到部分云上及外部用户机器存在安全漏洞被入侵，同时植入 watchdogs 挖矿病毒，出现 crontab 任务异常、系统文件被删除、CPU 异常等情况，并且会自动感染更多机器。攻击者主要利用 Redis 未授权访问入侵服务器并通过内网扫描和 known_hosts 历史登录尝试感染更多机器。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
