https://networkops.cn/guides/基础设施、网络运维、本地 AI 与产品开发实践。zh-CNhttps://networkops.cn/guides/network-fundamentals.htmlhttps://networkops.cn/guides/network-fundamentals.htmlMon, 13 Jul 2026 00:00:00 GMT从网络分类、拓扑、协议分层和 IP 地址出发，结合 Linux 配置、常用命令与故障排查流程，建立可验证的网络基础知识框架。https://networkops.cn/guides/linux-disk-management.htmlhttps://networkops.cn/guides/linux-disk-management.htmlMon, 15 Jun 2026 00:00:00 GMT上一篇《网络配置》讲的是数据如何离开主机、经过路由和网络到达其他系统；本篇回到主机内部，讨论数据如何从应用写入文件系统，再经过逻辑卷、设备映射和块设备落到物理盘、虚拟盘或云盘。https://networkops.cn/guides/vmware-datastore-management.htmlhttps://networkops.cn/guides/vmware-datastore-management.htmlMon, 15 Jun 2026 00:00:00 GMT上一篇完成了 vSwitch、端口组、VMkernel 与物理网络的衔接。本篇回到虚拟化平台最容易积累隐患的位置：数据存储。很多环境在建设初期只关心 LUN 或 NFS 共享能否挂载，等虚拟机数量增长后，才逐渐暴露容量水位失控、快照膨胀、精简置备超分、路径降级、数据存储命名混乱、迁移窗口。https://networkops.cn/guides/docker-compose-orchestration.htmlhttps://networkops.cn/guides/docker-compose-orchestration.htmlSun, 14 Jun 2026 00:00:00 GMT前五篇已经分别处理了镜像、容器、Dockerfile、网络和持久化。单独看每一项并不复杂，但当一个真实应用同时包含 Web 服务、后台任务、数据库、缓存、反向代理、多个网络和数据卷时，继续依靠手工执行 docker run 会迅速失控。https://networkops.cn/guides/twisted-pair-fiber.htmlhttps://networkops.cn/guides/twisted-pair-fiber.htmlSat, 13 Jun 2026 00:00:00 GMT上一篇 常见网络设备介绍 介绍了交换机、路由器、防火墙、AP、负载均衡等设备的责任边界。所有这些设备最终都要通过某种介质连接起来：办公室终端接入交换机通常用双绞线，机柜之间、楼层之间、园区之间和数据中心核心链路经常使用光纤。链路看起来只是“插一根线”，但真实运维里大量故障都发生在物理层和。https://networkops.cn/guides/harvester-network-configuration.htmlhttps://networkops.cn/guides/harvester-network-configuration.htmlFri, 12 Jun 2026 00:00:00 GMT前四篇已经完成 Harvester 的架构、安装、虚拟机和存储管理。第五篇进入最容易出现跨团队故障的部分：网络配置。虚拟机创建成功却拿不到地址、同 VLAN 互通但访问不了网关、迁移后连接中断、某些节点上的虚拟机正常而另一些节点异常，这些现象通常不是单一组件故障，而是来宾系统、KubeV。https://networkops.cn/guides/linux-network-configuration.htmlhttps://networkops.cn/guides/linux-network-configuration.htmlFri, 12 Jun 2026 00:00:00 GMT上一篇《系统服务管理》把长期运行的软件纳入 systemd 生命周期。本篇继续向外扩展：服务要被用户访问、要连接数据库、要解析域名、要获取时间、要上报监控，最终都依赖主机网络。Linux 网络配置看起来只是 IP、掩码、网关和 DNS 四个字段，生产故障却经常跨越网卡驱动、链路聚合、VL。https://networkops.cn/guides/filebeat-log-collection.htmlhttps://networkops.cn/guides/filebeat-log-collection.htmlThu, 11 Jun 2026 00:00:00 GMT在少量服务器上，管理员可以用 scp、定时脚本或共享目录集中日志。但当主机数量增加、日志持续轮转、网络偶尔中断、应用产生多行异常堆栈时，简单复制很快失效。真正的日志采集需要解决一组状态问题：https://networkops.cn/guides/linux-service-management.htmlhttps://networkops.cn/guides/linux-service-management.htmlThu, 11 Jun 2026 00:00:00 GMT上一篇《进程管理》解决的是运行时观察与处置问题：进程从哪里来、消耗了什么资源、处于什么状态、该发送什么信号，以及如何在事故中保留现场。但生产服务器不能依赖管理员登录后手工执行命令，也不能把长期任务寄托在 nohup、screen 或某个无人维护的 Shell 会话里。一个可交付的服务至少。https://networkops.cn/guides/common-network-devices.htmlhttps://networkops.cn/guides/common-network-devices.htmlSat, 06 Jun 2026 00:00:00 GMT上一篇《IP 地址与子网划分》解决了地址、前缀、网关和子网边界的问题。地址规划完成后，数据还需要经过一系列设备才能从终端到达服务器：无线终端先接入 AP，帧进入交换机，跨网段流量交给三层网关，经过路由和安全策略，再由服务入口分发给后端应用。https://networkops.cn/guides/vswitch-network-configuration.htmlhttps://networkops.cn/guides/vswitch-network-configuration.htmlThu, 04 Jun 2026 00:00:00 GMT前一篇完成了虚拟机生命周期管理，重点解决“虚拟机如何标准化交付、变更和退役”。到了生产环境，虚拟机能不能稳定运行，很大一部分取决于网络：端口组是否一致、VLAN 是否正确、上联是否冗余、VMkernel 服务是否隔离、vMotion 和存储网络是否被错误地混在管理网络里、分布式交换机变更。https://networkops.cn/guides/docker-volumes-persistence.htmlhttps://networkops.cn/guides/docker-volumes-persistence.htmlWed, 03 Jun 2026 00:00:00 GMT前四篇已经完成了 Docker 的基本运行链路：理解镜像和容器，能安装 Docker Engine，能用 Dockerfile 构建应用镜像，也能把容器接入自定义网络并发布端口。从这一篇开始，容器不再只是“可启动的进程”，而要承载真实业务状态。只要应用需要保存数据库文件、用户上传内容、队。https://networkops.cn/guides/harvester-storage-management.htmlhttps://networkops.cn/guides/harvester-storage-management.htmlTue, 02 Jun 2026 00:00:00 GMT前三篇已经完成了 Harvester 的定位、部署和虚拟机生命周期管理。到了第四篇，重点转向平台能不能长期稳定承载业务数据。虚拟机是否能创建成功，只说明控制平面、镜像、网络和调度大体可用；虚拟机是否能在节点维护、磁盘故障、容量增长、快照恢复和备份演练中保持可控，主要取决于存储管理。https://networkops.cn/guides/kibana-visualization.htmlhttps://networkops.cn/guides/kibana-visualization.htmlMon, 01 Jun 2026 00:00:00 GMTKibana 不是一个“漂亮报表工具”这么简单。它是 Elastic Stack 面向人的操作界面，承担三类职责：第一，帮助工程师探索 Elasticsearch 里的原始文档；第二，把字段、查询、聚合转换成图表和仪表板；第三，作为运维、安全、可观测性、告警、空间、权限等功能的入口。https://networkops.cn/guides/linux-process-management.htmlhttps://networkops.cn/guides/linux-process-management.htmlFri, 29 May 2026 00:00:00 GMT完成软件包管理之后，Linux 系统管理进入运行时层面的核心主题：进程管理。软件包把二进制、配置文件、库文件和 systemd 单元安装到系统中，但真正消耗 CPU、内存、文件句柄、端口、磁盘 I/O 和网络连接的是进程。一个服务启动失败、CPU 长时间打满、内存持续增长、端口被占用、僵。https://networkops.cn/guides/ip-addressing-subnetting.htmlhttps://networkops.cn/guides/ip-addressing-subnetting.htmlWed, 27 May 2026 00:00:00 GMT上一篇《TCP/IP 协议栈》把应用数据、端口、IP、MAC、路由和 ARP 放在同一条通信链路里理解。本文继续向网络层的核心能力深入：IP 地址如何标识主机，子网如何划分边界，掩码如何决定一台主机是直接发送还是交给网关。https://networkops.cn/guides/vm-lifecycle-management.htmlhttps://networkops.cn/guides/vm-lifecycle-management.htmlWed, 27 May 2026 00:00:00 GMT前一篇完成了 vCenter Server 部署，vSphere 环境已经从单台 ESXi 主机管理进入集中控制阶段。到了这一篇，管理对象从平台本身转向虚拟机：如何创建一台标准虚拟机，如何把它转换成可复用模板，如何通过克隆、内容库、自定义规范和资源策略交付一致的工作负载，如何在运行期处理。https://networkops.cn/guides/docker-network-configuration.htmlhttps://networkops.cn/guides/docker-network-configuration.htmlTue, 26 May 2026 00:00:00 GMT前面三篇已经完成了 Docker 的基本运行链路：知道镜像、容器、仓库之间的关系，能在 Linux 服务器上安装 Docker Engine，也能用 Dockerfile 把自己的应用构建成镜像。从这一篇开始，容器不再只是一个能启动的进程，而要真正接入主机、其他容器、局域网和外部服务。这。https://networkops.cn/guides/linux-package-management.htmlhttps://networkops.cn/guides/linux-package-management.htmlMon, 25 May 2026 00:00:00 GMT完成文件系统管理之后，Linux 系统管理进入另一个高频但容易被低估的主题：软件包管理。系统管理员每天都会安装工具、升级安全补丁、清理旧内核、配置第三方仓库、处理依赖冲突、定位服务文件来自哪个包、回滚一次失败升级。看起来只是 apt install 或 dnf install 的问题，实。https://networkops.cn/guides/harvester-vm-management.htmlhttps://networkops.cn/guides/harvester-vm-management.htmlSat, 23 May 2026 00:00:00 GMT前两篇已经完成了 Harvester 的定位、核心架构和安装部署。到了第三篇，重点从“平台能不能跑起来”转向“虚拟机能不能被稳定、可重复、可排障地交付”。对于习惯 VMware、Proxmox 或传统 KVM 的运维人员来说，Harvester 的虚拟机管理界面并不难上手，但真正需要理解。https://networkops.cn/guides/linux-filesystem-management.htmlhttps://networkops.cn/guides/linux-filesystem-management.htmlFri, 22 May 2026 00:00:00 GMT完成用户与权限管理之后，Linux 系统管理进入一个更贴近日常运维现场的主题：文件系统管理。服务器上的应用、日志、数据库、备份、容器镜像、临时文件和用户数据，最终都会落到某个文件系统里。磁盘空间满了、inode 用尽、挂载参数错误、/etc/fstab 写错导致系统无法启动、日志目录占满。https://networkops.cn/guides/vcenter-server-deployment.htmlhttps://networkops.cn/guides/vcenter-server-deployment.htmlThu, 21 May 2026 00:00:00 GMT前两篇分别建立了 vSphere 的核心概念和 ESXi 存储基础。本篇进入集中管理层：部署 vCenter Server Appliance（VCSA），把单台 ESXi 主机管理升级为可承载集群、权限、模板、生命周期管理和自动化 API 的平台。https://networkops.cn/guides/tcp-ip-protocol-stack.htmlhttps://networkops.cn/guides/tcp-ip-protocol-stack.htmlThu, 21 May 2026 00:00:00 GMT这个总览把 TCP/IP 四层模型、封装过程和常见排障现象放到同一视角，后文会按这些层级展开。https://networkops.cn/guides/dockerfile-image-build.htmlhttps://networkops.cn/guides/dockerfile-image-build.htmlWed, 20 May 2026 00:00:00 GMT前两篇已经完成了 Docker 的概念铺垫和运行层操作：知道镜像、容器、仓库之间的关系，也能在 Ubuntu 主机上安装 Docker Engine，并用 docker run 启动、查看、停止和清理容器。从这一篇开始，重点从“运行别人发布的镜像”转向“把自己的应用做成可交付的镜像”。https://networkops.cn/guides/docker-installation-basic-commands.htmlhttps://networkops.cn/guides/docker-installation-basic-commands.htmlTue, 19 May 2026 00:00:00 GMT上一篇已经把 Docker 的核心概念讲清楚了：镜像是交付物，容器是运行实例，仓库负责分发，Docker Engine 通过 containerd、runc、Namespace、Cgroup 和 OverlayFS 把应用隔离起来运行。本文进入真正的操作层：在一台 Linux 主机上安装。https://networkops.cn/guides/linux-user-permission-management.htmlhttps://networkops.cn/guides/linux-user-permission-management.htmlTue, 19 May 2026 00:00:00 GMT完成系统安装与初始化之后，下一项基础工作就是建立可控的账号和权限体系。Linux 服务器的权限管理不是单个命令的问题，而是一套围绕身份、认证、授权、文件访问控制、提权审计和账号生命周期的治理机制。账号创建得随意、共享 root 密码、业务目录权限过宽、sudo 规则没有边界，都会让后续的。https://networkops.cn/guides/docker-core-concepts.htmlhttps://networkops.cn/guides/docker-core-concepts.htmlSun, 17 May 2026 00:00:00 GMT这个交付链路把传统部署痛点、镜像构建、仓库分发和容器运行串成一条标准路径。https://networkops.cn/guides/esxi-storage-management.htmlhttps://networkops.cn/guides/esxi-storage-management.htmlSat, 16 May 2026 00:00:00 GMT存储是虚拟化基础设施的三大核心资源之一（计算、存储、网络），在企业级 vSphere 环境中，存储系统的设计直接决定了虚拟机的性能、可用性和可管理性。与物理服务器时代不同，虚拟化环境中的存储面临更为复杂的需求：多个虚拟机共享同一存储资源池、需要支持在线迁移（vMotion）、高可用（HA。https://networkops.cn/guides/elasticsearch-installation-configuration.htmlhttps://networkops.cn/guides/elasticsearch-installation-configuration.htmlFri, 15 May 2026 00:00:00 GMT上一篇讲架构，这一篇只做一件事：把 Elasticsearch 作为 ELK 的存储和查询底座稳定装起来，并留下生产化配置的判断框架。安装本身不难，难的是不要把一个临时单节点误当生产集群，也不要跳过安全、系统参数、数据目录、证书、密码、分片和生命周期这些后面一定会影响 Logstash。https://networkops.cn/guides/logstash-pipeline-configuration.htmlhttps://networkops.cn/guides/logstash-pipeline-configuration.htmlFri, 15 May 2026 00:00:00 GMT前一篇把 Elasticsearch 装起来，并明确了数据流、模板、权限和生命周期。本文接着处理中间层：Logstash。它不是所有日志链路都必须出现的组件，但当日志来源复杂、字段需要治理、解析失败需要复盘、写入前需要脱敏或路由时，Logstash 仍然是 ELK Stack 里最适合承。https://networkops.cn/guides/vmware-vsphere-core-concepts.htmlhttps://networkops.cn/guides/vmware-vsphere-core-concepts.htmlFri, 15 May 2026 00:00:00 GMT虚拟化（Virtualization）是现代数据中心和云计算基础设施的基石技术。它将物理硬件资源（计算、存储、网络）抽象为逻辑资源池，使多个操作系统和应用程序能够在一台物理服务器上独立、安全地运行。这项技术从根本上改变了企业 IT 基础设施的交付、管理和消费方式。https://networkops.cn/guides/osi-seven-layer-model.htmlhttps://networkops.cn/guides/osi-seven-layer-model.htmlSat, 09 May 2026 00:00:00 GMTOSI（Open Systems Interconnection）七层模型是计算机网络中最基础、最重要的概念框架。它由国际标准化组织（ISO）于1984年发布，将网络通信划分为7个逻辑层级，每一层负责特定的通信功能。理解 OSI 七层模型，是掌握所有网络技术的基石——无论你是在配置交换机。https://networkops.cn/guides/harvester-installation.htmlhttps://networkops.cn/guides/harvester-installation.htmlFri, 08 May 2026 00:00:00 GMT上一篇建立了 Harvester 的架构心智模型：裸金属节点提供计算、磁盘和网络，Kubernetes 是控制面，KubeVirt 运行虚拟机，Longhorn 提供分布式块存储，Multus 承载多网络，Harvester UI/API 把这些能力包装成虚拟化平台。本篇进入安装部署。重。https://networkops.cn/guides/netbox-api-guide.htmlhttps://networkops.cn/guides/netbox-api-guide.htmlWed, 06 May 2026 00:00:00 GMT前面几篇已经把 NetBox 的基础安装、IPAM、DCIM、电路和连接管理串起来。本篇讨论 API。NetBox API 的核心价值不是“用脚本替代点页面”，而是让 NetBox 成为基础设施自动化的可信数据源：监控系统从它读取目标，配置生成从它读取期望状态，变更系统把审批后的结果写回。https://networkops.cn/guides/netbox-dcim-management.htmlhttps://networkops.cn/guides/netbox-dcim-management.htmlSun, 03 May 2026 00:00:00 GMT上一篇完成 IPAM，把地址空间、VRF、Prefix、VLAN 和 IP Address 建成可治理对象。本篇进入 DCIM。DCIM 在 NetBox 中不是“设备资产表”，而是把站点、位置、机架、设备类型、设备、模块、接口、电源、控制台、库存件和连接关系组织成一套结构化模型。只有。https://networkops.cn/guides/netbox-ipam-management.htmlhttps://networkops.cn/guides/netbox-ipam-management.htmlSun, 03 May 2026 00:00:00 GMT前两篇完成了 NetBox 的部署路线，本篇开始把 NetBox 真正用起来。IPAM 不是“把 IP 地址录进系统”，而是把地址空间、路由隔离、二层域、用途、状态、归属、分配和审计组织成一套可被团队和自动化共同使用的模型。只有先把模型设计清楚，后续 DCIM、连接、API 和自动化才不。https://networkops.cn/guides/linux-installation-initialization.htmlhttps://networkops.cn/guides/linux-installation-initialization.htmlSat, 02 May 2026 00:00:00 GMT在选择了合适的 Linux 发行版之后，系统管理员面临的下一个关键任务就是完成系统的安装和初始化配置。这个过程看似简单，但实际上涉及众多技术细节和最佳实践，直接影响系统的安全性、稳定性和可维护性。一个标准化的安装和初始化流程，是构建企业级 IT 基础设施的基石。https://networkops.cn/guides/netbox-docker-compose-deployment.htmlhttps://networkops.cn/guides/netbox-docker-compose-deployment.htmlFri, 01 May 2026 00:00:00 GMT上一篇采用传统 Linux 服务方式部署 NetBox。本篇改用社区维护的 netbox-community/netbox-docker 项目，把 NetBox、PostgreSQL、Redis 和 worker 编排为一套 Docker Compose 应用。目标不是只让首页出现，而是。https://networkops.cn/guides/netbox-source-installation.htmlhttps://networkops.cn/guides/netbox-source-installation.htmlFri, 01 May 2026 00:00:00 GMT上一篇明确了 NetBox 的定位和数据治理边界。本篇进入传统 Linux 安装路线：在 Ubuntu 24.04 上准备 PostgreSQL、Redis、NetBox 应用、Gunicorn、后台 worker 和 Nginx，最终得到一套可通过 systemd 管理、可升级、可备份。https://networkops.cn/guides/zabbix-grafana-integration.htmlhttps://networkops.cn/guides/zabbix-grafana-integration.htmlThu, 30 Apr 2026 00:00:00 GMTZabbix 已经具备最新数据、图形、仪表板、问题和服务视图，接入 Grafana 的目的不应是重复建设另一套监控入口。Grafana 更适合把多个系统的数据放到统一叙事中，为 NOC 大屏、业务容量、跨环境对比和管理视角提供灵活展示；Zabbix 仍负责采集、触发器、事件、通知和监控对。https://networkops.cn/guides/zabbix-distributed-monitoring.htmlhttps://networkops.cn/guides/zabbix-distributed-monitoring.htmlTue, 28 Apr 2026 00:00:00 GMT前两篇分别处理服务器和数据库纳管。当监控对象分布在多个数据中心、工厂、分支、云区域和安全区时，让所有 Agent、SNMP 设备、HTTP 检查都直接连接中心 Zabbix Server，会带来防火墙规则复杂、广域网不稳定、采集延迟和中心采集进程压力。Zabbix Proxy 用于把采集。https://networkops.cn/guides/linux-distribution-selection.htmlhttps://networkops.cn/guides/linux-distribution-selection.htmlMon, 20 Apr 2026 00:00:00 GMTLinux 系统管理的第一步不是背命令，而是选对发行版。发行版一旦进入生产环境，就会影响后续几年的补丁策略、软件仓库、内核版本、硬件认证、商业支持、自动化工具、团队技能和故障处理方式。选错发行版不一定会让系统马上不可用，但会把维护成本慢慢推高：补丁没人敢打，软件包版本对不上，厂商不支持。https://networkops.cn/guides/harvester-architecture.htmlhttps://networkops.cn/guides/harvester-architecture.htmlFri, 17 Apr 2026 00:00:00 GMTHarvester 是 SUSE/Rancher 生态中的开源超融合基础设施平台。它面向裸金属服务器，把虚拟机管理、分布式块存储、虚拟网络、监控和 Rancher 集成放在同一套 Kubernetes 底座上。对于习惯 VMware vSphere、Proxmox 或 OpenStack。https://networkops.cn/guides/zabbix-architecture.htmlhttps://networkops.cn/guides/zabbix-architecture.htmlThu, 16 Apr 2026 00:00:00 GMT这篇是 Zabbix 实战系列的入口。读完以后，你应该能回答三个问题：Zabbix 适合解决什么监控问题，它由哪些核心组件组成，以及从单机试点走向生产分布式监控时，哪些边界必须提前设计。https://networkops.cn/guides/zabbix-server-deployment.htmlhttps://networkops.cn/guides/zabbix-server-deployment.htmlThu, 16 Apr 2026 00:00:00 GMT上一篇 Zabbix简介与架构 建立了 Zabbix 的组件模型：Server 是中心逻辑，Database 是状态与历史仓库，Frontend 是人的入口，Agent/Proxy 是采集边界。本文进入安装部署，但目标不是“把登录页打开”这么简单，而是把一个可以继续接入 Agent、模板。https://networkops.cn/guides/elk-stack-architecture.htmlhttps://networkops.cn/guides/elk-stack-architecture.htmlThu, 16 Apr 2026 00:00:00 GMTELK Stack 最初指 Elasticsearch、Logstash、Kibana 三个组件：Elasticsearch 负责存储、搜索和分析，Logstash 负责采集和处理数据，Kibana 负责查询和可视化。后来 Beats、Elastic Agent、Integrations。https://networkops.cn/guides/netbox-asset-relationship-modeling.htmlhttps://networkops.cn/guides/netbox-asset-relationship-modeling.htmlWed, 08 Apr 2026 00:00:00 GMT- 这篇文章从 IP 纳管继续往前走，解决“知道这个地址存在，但不知道它属于谁”的建模问题。 - 核心思路是借助 SNMP 做能力识别，再把 IP、接口和设备之间的关系自动补齐。 - 读完它，你会更清楚 NetBox 为什么不能只做地址台账，而应该成为资产关系的事实中心。https://networkops.cn/guides/netbox-interface-neighbor-discovery.htmlhttps://networkops.cn/guides/netbox-interface-neighbor-discovery.htmlWed, 08 Apr 2026 00:00:00 GMT- 这篇文章把关注点从“IP 属于谁”继续推进到“接口是什么状态、邻居链路是否可信”。 - 方案核心是先用 SNMP 补齐接口，再用 LLDP 自动生成拓扑，并保留人工确认这一层兜底机制。 - 如果你希望 NetBox 支撑自动化研判，而不是只存事实，这篇就是关键过渡。https://networkops.cn/guides/netbox-ip-asset-audit.htmlhttps://networkops.cn/guides/netbox-ip-asset-audit.htmlWed, 08 Apr 2026 00:00:00 GMT- 这篇文章专门解决“IP 已经纳管，但状态仍靠人维护”的问题，把状态判断改成可执行的自动治理规则。 - 方案由两个脚本组成：一个负责事实采集，一个负责状态决策与通知，避免采集逻辑和治理逻辑缠在一起。 - 它适合作为 1.0 的补强篇，帮助你把 NetBox 从台账系统推进到可持续治理系。https://networkops.cn/guides/netbox-ip-asset-automation.htmlhttps://networkops.cn/guides/netbox-ip-asset-automation.htmlWed, 08 Apr 2026 00:00:00 GMT- 这篇文章把 IP 发现 -> NetBox 纳管 -> 审计告警 串成第一条可运行的自动化闭环。 - 重点不在单一脚本，而在如何把 Orb、Diode、Python 和钉钉组合成长期可维护的资产治理流程。 - 如果你已经完成基础部署，建议从这篇开始进入 NetBox 的工程化使用阶段。https://networkops.cn/guides/netbox-napalm-huawei-integration.htmlhttps://networkops.cn/guides/netbox-napalm-huawei-integration.htmlWed, 08 Apr 2026 00:00:00 GMT- 这篇文章解释为什么在 NetBox 里接入 NAPALM，不是为了做监控，而是为了补齐“现状数据”的取数能力。 - 重点内容包括插件安装、依赖关系、华为 VRP 驱动适配，以及 Source of Truth 与实时取数之间的职责边界。 - 它对应系列里的“能力扩展”阶段，适合在接口。https://networkops.cn/guides/netbox-ubuntu-deployment-practice.htmlhttps://networkops.cn/guides/netbox-ubuntu-deployment-practice.htmlWed, 08 Apr 2026 00:00:00 GMT- 这篇文章是整个 NetBox实战 系列的起点，覆盖 Ubuntu 环境下从依赖安装到 Web 服务启动的完整落地过程。 - 重点说明 NetBox 为什么适合作为基础设施 Source of Truth，以及 PostgreSQL、Gunicorn、Nginx 这几段最容易出错的部署。https://networkops.cn/guides/netbox-orb-diode-multisite-discovery.htmlhttps://networkops.cn/guides/netbox-orb-diode-multisite-discovery.htmlSun, 22 Mar 2026 00:00:00 GMT- 这篇文章聚焦多站点发现链路，核心是把 Orb Agent -> Diode -> NetBox 这一段稳定跑通。 - 内容不仅覆盖 CentOS 7 上的安装与连通问题，也解释了为什么“发现成功”并不等于“资产模型完整”。 - 它适合放在部署篇之后阅读，作为后续 IP 纳管和设备建模。https://networkops.cn/guides/netbox-upgrade-rollback-practice.htmlhttps://networkops.cn/guides/netbox-upgrade-rollback-practice.htmlFri, 20 Feb 2026 00:00:00 GMT- 这篇文章不再讨论新功能，而是聚焦生产环境最实际的升级、验证和回滚问题。 - 核心目标是把 4.4.7 -> 4.5.3 的升级流程做成可重复、可验证、可快速撤回的操作手册。 - 如果你的 NetBox 已经接入脚本、插件或生产流程，这篇比功能扩展更值得优先准备。https://networkops.cn/guides/zabbix-performance-optimization.htmlhttps://networkops.cn/guides/zabbix-performance-optimization.htmlTue, 29 Apr 2025 00:00:00 GMT上一篇把采集压力分散到 Proxy，但 Proxy 只能搬走部分采集工作，中心 Server 仍要接收数据、执行预处理、计算触发器、生成事件并写入数据库。监控规模扩大后，真正困难的不是找到一组“高性能参数”，而是识别当前瓶颈究竟位于采集、接收、预处理、缓存、数据库、housekeepin。https://networkops.cn/guides/zabbix-items-triggers.htmlhttps://networkops.cn/guides/zabbix-items-triggers.htmlTue, 22 Apr 2025 00:00:00 GMT前一篇完成 Agent 接入后，Zabbix 才真正有了稳定的数据来源。接下来要解决的问题不是“能不能采到值”，而是“采什么、多久采一次、怎样解释、什么时候算异常、异常是否值得通知”。这就是监控项和触发器的职责。https://networkops.cn/guides/zabbix-database-monitoring.htmlhttps://networkops.cn/guides/zabbix-database-monitoring.htmlMon, 27 Jan 2025 00:00:00 GMT服务器监控可以告诉我们数据库主机的 CPU、内存、磁盘和网络是否异常，却不能说明数据库内部是否还能正常提供服务。连接池可能耗尽，复制可能中断，锁等待可能持续，缓存命中率可能下降，备份可能失败，而操作系统指标仍然看起来正常。数据库监控必须进入实例内部，同时又要遵守最小权限、低开销和不影响业。https://networkops.cn/guides/zabbix-server-monitoring.htmlhttps://networkops.cn/guides/zabbix-server-monitoring.htmlSun, 26 Jan 2025 00:00:00 GMT第 03 篇已经讲过 Agent 2、主动与被动模式、TLS/PSK、UserParameter 和批量接入。本篇不重复安装过程，而是回答服务器进入 Zabbix 后更关键的问题：一台服务器到底应该监控什么，Linux 与 Windows 的基线有什么差异，模板和宏怎样组织，哪些服务和进。https://networkops.cn/guides/zabbix-network-monitoring.htmlhttps://networkops.cn/guides/zabbix-network-monitoring.htmlSat, 25 Jan 2025 00:00:00 GMT网络监控是 Zabbix 最常见也最容易失控的场景之一。网络设备数量多、接口数量多、链路状态复杂、厂商 MIB 差异明显，如果只把交换机、路由器、防火墙简单加进 Zabbix，很快就会遇到接口告警泛滥、SNMP 失败、拓扑不准、链路利用率看不懂、维护窗口缺失等问题。https://networkops.cn/guides/zabbix-dashboard-design.htmlhttps://networkops.cn/guides/zabbix-dashboard-design.htmlFri, 24 Jan 2025 00:00:00 GMT前面几篇已经完成了 Zabbix 的基础架构、Server 部署、Agent 接入、监控项触发器和告警通知。到这里，平台已经可以采集数据、识别异常并把问题推给负责人。仪表盘解决的是另一类需求：人在主动观察系统时，如何快速看懂整体状态、定位异常区域、判断趋势和支撑复盘。https://networkops.cn/guides/zabbix-alert-notifications.htmlhttps://networkops.cn/guides/zabbix-alert-notifications.htmlThu, 23 Jan 2025 00:00:00 GMT前一篇讲的是监控项和触发器。触发器把数据解释成问题，告警配置则决定这个问题要不要通知、通知谁、什么时候通知、通过什么渠道通知、恢复时怎样收口。很多团队把告警建设理解成“接上邮件、企业微信、钉钉或短信”，这只是最后一公里。真正困难的是告警治理：让正确的问题在正确时间到达正确的人，并且不会把。https://networkops.cn/guides/zabbix-agent-management.htmlhttps://networkops.cn/guides/zabbix-agent-management.htmlTue, 21 Jan 2025 00:00:00 GMT前两篇已经把 Zabbix 的整体架构和 Server 安装基线交代清楚了。从这一篇开始，监控平台真正进入“接入对象”的阶段。Zabbix Server 本身再稳定，如果 Agent 接入方式混乱、主机名不一致、TLS 没有统一、主动模式和被动模式随意混用，后面做监控项、触发器、告警和报。https://networkops.cn/guides/netbox-circuit-connection-management.htmlhttps://networkops.cn/guides/netbox-circuit-connection-management.htmlMon, 15 Jan 2024 00:00:00 GMT上一篇把 DCIM 的 Site、Location、Rack、Device、Interface、Module、电源和控制台对象梳理清楚。本篇继续处理物理层和运营商线路：设备之间如何连接，配线架如何表达，专线如何从供应商网络进入站点，故障时如何追踪路径，变更前如何判断影响范围。