40-可观测性与运维平台 / NetBox实战

NetBox 实战

围绕多站点发现、IP 资产治理、关系建模、邻居发现、NAPALM 和升级回滚的 NetBox 实战。

01-NetBox部署实战：在 Ubuntu 上完成 v4.4.7 安装与基础配置

- 这篇文章是整个 NetBox实战系列的起点，覆盖 Ubuntu 环境下从依赖安装到 Web 服务启动的完整落地过程。 - 重点说明 NetBox 为什么适合作为基础设施 Source of Truth，以及 PostgreSQL、Gunicorn、Nginx 这几段最容易出错的部署。

- 这篇文章聚焦多站点发现链路，核心是把 Orb Agent -> Diode -> NetBox 这一段稳定跑通。 - 内容不仅覆盖 CentOS 7 上的安装与连通问题，也解释了为什么“发现成功”并不等于“资产模型完整”。 - 它适合放在部署篇之后阅读，作为后续 IP 纳管和设备建模。

- 这篇文章把 IP 发现 -> NetBox 纳管 -> 审计告警串成第一条可运行的自动化闭环。 - 重点不在单一脚本，而在如何把 Orb、Diode、Python 和钉钉组合成长期可维护的资产治理流程。 - 如果你已经完成基础部署，建议从这篇开始进入 NetBox 的工程化使用阶段。

- 这篇文章专门解决“IP 已经纳管，但状态仍靠人维护”的问题，把状态判断改成可执行的自动治理规则。 - 方案由两个脚本组成：一个负责事实采集，一个负责状态决策与通知，避免采集逻辑和治理逻辑缠在一起。 - 它适合作为 1.0 的补强篇，帮助你把 NetBox 从台账系统推进到可持续治理系。

- 这篇文章从 IP 纳管继续往前走，解决“知道这个地址存在，但不知道它属于谁”的建模问题。 - 核心思路是借助 SNMP 做能力识别，再把 IP、接口和设备之间的关系自动补齐。 - 读完它，你会更清楚 NetBox 为什么不能只做地址台账，而应该成为资产关系的事实中心。

- 这篇文章把关注点从“IP 属于谁”继续推进到“接口是什么状态、邻居链路是否可信”。 - 方案核心是先用 SNMP 补齐接口，再用 LLDP 自动生成拓扑，并保留人工确认这一层兜底机制。 - 如果你希望 NetBox 支撑自动化研判，而不是只存事实，这篇就是关键过渡。

- 这篇文章解释为什么在 NetBox 里接入 NAPALM，不是为了做监控，而是为了补齐“现状数据”的取数能力。 - 重点内容包括插件安装、依赖关系、华为 VRP 驱动适配，以及 Source of Truth 与实时取数之间的职责边界。 - 它对应系列里的“能力扩展”阶段，适合在接口。

- 这篇文章不再讨论新功能，而是聚焦生产环境最实际的升级、验证和回滚问题。 - 核心目标是把 4.4.7 -> 4.5.3 的升级流程做成可重复、可验证、可快速撤回的操作手册。 - 如果你的 NetBox 已经接入脚本、插件或生产流程，这篇比功能扩展更值得优先准备。