DEV Community: Tia Zanella

When Go meets simplicity over Python or Ansible

Tia Zanella — Fri, 19 Jun 2026 18:21:32 +0000

We constantly hear that Ansible and Python are apparently the only ways to automate networks, today I even listen in a conversation "Python is the industry standard" probably I missed the RFC document or probably the guy was referring to a sales standard, but back to us what happens when the framework, the platform or the software we are using becomes heavier than the problem to solve?

There is a moment where automation becomes necessary, not because we want to look modern, not because every task deserves a framework and not simply because adding automation automatically means we are doing things better. It becomes necessary because repeating the same command collection manually across many devices is slow, risky, boring and almost impossible to diff and validate properly especially under pressure.

For this reason I built the Cisco Go Collector during a real migration activity with a very practical goal: collect configuration and command outputs from Cisco devices in an easily repeatable way, without forcing every colleague involved in the process to become developers or to install an automation stack just to run a super simple flow.

The idea was simple:

define the devices in a CSV which is the comfort zone for everyone
define the commands in the same CSV file, super simple and organized to manage one row per device
run a portable Go binary against that CSV file
collect the outputs in organized text files
archive the result as operational evidence that can be easily diff

That is it!

super lightweight to run
no Python virtual environment
no Ansible playbook structure
no inventory hierarchy
no framework onboarding
no additional runtime or software on corporate managed workstations
just a CSV file and a compiled binary

The automation and AI trap when the solution is heavier than the problem to solve

I love automation and I fully support AI if used the proper way, but we have to find a balance and recognize when to choose one tool over the other and specially one programming language over the other.

In this specific case, I wanted something very fast, lightweight, portable and executable freely in a managed environment.
The immediate thought for many would be: let's write a Python script, it would work, but then you introduce dependencies overhead of security risks, you have to ask users to install the environment, manage virtual environments and deal with pip we all know the story nearly impossible to obtain in managed environments and indeed quite useless to run a simple collector.

Using Ansible for a simple collection task is like using a bazooka to kill a mosquito, frameworks like Netmiko, Nornir, pyATS, and similar ecosystems are excellent when the problem requires state management, reusable workflows, validation logic, abstraction layers, structured inventory, compliance, CI/CD integration, or large-scale governance.

But I think not every operational task requires that level of machinery and complexity overhead, sometimes the real problem is much smaller: I need to simply connect to many devices, run a known list of commands, save the outputs and make the result easy to review among my colleagues as simply as that!
In that scenario, the complexity of the automation environment can become bigger than the task itself and in my opinion team balance matters most then the technology used to achieve the result.

Developing Python scripts or Ansible YAML requires a specific level of knowledge of what we do, whereas using a CSV file is straightforward for everyone, this is especially true in managed corporate environments, where engineers often work on locked-down laptops, jump servers, or controlled workstations, installing Python packages or external dependencies may require approvals. Even when installation is possible, supportability becomes part of the problem:

who owns the runtime?
who updates the dependencies?
who validates the Python version?
who explains the playbook structure to non-developers?
who supports the colleague who only needs to run some migration checks at 02:00 during a change window?

Those questions matter.
Automation is not only about what is technically possible, automation is also about what is operationally usable and make life easy!

So why not just use Ansible?

Ansible is a great tool, for many network automation use cases, it is the graal.

It gives you inventories, variables, modules, playbooks, idempotency, roles, collections and a broad ecosystem. If the goal is configuration management, desired state, multi-step orchestration or repeatable infrastructure workflows, Ansible is a serious candidate.

But for this project, I was not trying to model the network state.

I was not trying to push configuration
I was not trying to build a source-of-truth-driven workflow
I was not trying to create a full orchestration layer
I was not trying to introduce a new automation culture during a migration window

The goal was more direct: let network engineers declare what they want to collect in a CSV, then execute it consistently.
That may sound too simple to be truth, but simplicity is exactly the strength here.

a CSV file can be opened by everyone
it can be reviewed before execution
it can be attached to a change request
it can be versioned in Git
it can be edited by people who do not write code
it can be validated by another engineer before the migration starts and edit super fast in case of need

In this use case, the CSV is not a limitation, it became the operational contract.

The CSV as the human interface

The design starts from a very basic assumption as the input should be understandable by the whole team.
A typical CSV file describes:

datacenter	room	rack	hostname	ip	platform	category	command	target_ip	vrf
DC1	ROOM-A	12	MPX01	10.10.10.100	nx-os	common	show clock
DC1	ROOM-A	12	MPX01	10.10.10.100	nx-os	common	show vlan brief
DC1	ROOM-A	12	MPX01	10.10.10.100	nx-os	common	show pbr static summary
DC1	ROOM-A	12	MPX01	10.10.10.100	nx-os	specialized	show ip route ospf-xxx vrf all
DC1	ROOM-A	12	MPX01	10.10.10.100	nx-os	specialized	show ip ospf neighbor vrf all
DC1	ROOM-B	58	MPX02	10.10.30.100	ios-xe	connectivity	traceroute	10.0.0.1	VRFNAME
DC1	ROOM-B	58	MPX02	10.10.30.100	ios-xe	connectivity	ping	10.0.0.1	VRFNAME
DC1	ROOM-B	60	MPX03	10.10.20.100	nx-os	connectivity	traceroute	1.1.1.1
DC1	ROOM-B	60	MPX03	10.10.20.100	nx-os	connectivity	ping	1.1.1.1

This gives the team a simple way to answer three important questions before execution and act fast on changes:

which devices are involved?
which commands will be executed?
where will the evidence be stored?

That transparency is extremely important during migrations when pressure is high, ambiguity is expensive as like ask someone to develop a solution to achieve this simple result. A deterministic CSV file viceversa is easier to review than a conversation in a chat, easier to validate than a copy-paste checklist and easier to archive than manual terminal history.

Why Go?

Go was a very practical choice. Its value is not that it's fashionable, but that it allows the tool to be distributed as a single compiled executable and it is blazing fast when handling parallel requests.

For this specific use case, that matters more than language elegance, compiled binary is easier to distribute in a locked-down environment. It reduces the need for local runtime preparation and avoids asking every operator to install Python packages, manage virtual environments or align dependency versions.

The operational model becomes simple:

prepare CSV -> run binary -> collect output

That is the whole workflow, for a migration team, this is powerful because the tool becomes almost invisible. People do not need to understand the internal code to use it they only need to understand the CSV and wait for the expected output.

That is the kind of automation I like: not impressive from the outside, but extremely useful when the team is under pressure.

Internal architecture

The project is intentionally small, but not random and available to welcome additional scenarios, the internal logic can be seen as four layers.

CSV input -> Device and command model -> SSH execution engine -> Structured output writer

1. CSV loader

The loader reads the CSV header, validates the required columns and creates a list of devices.

Required fields include:

datacenter, room, zone, hostname, ip, platform, category, command

Optional fields include:

target_ip, vrf

Commands are grouped by hostname, so each device can have multiple commands attached to it this avoids treating every CSV row as an isolated connection task and gives the execution layer a cleaner device-centric model.

2. Platform-aware command builder

Most commands are executed exactly as written if the command is a normal CLI command such as:

show version
show interface status
show ip route
show running-config

the collector sends the command directly to the device, for commands such as ping and traceroute, the tool can generate the correct Cisco syntax using the optional target_ip and vrf fields, this matters because syntax differs between platforms.

For NX-OS, the structure is:

ping 10.10.10.10 vrf management

For IOS-XE, the structure is:

ping vrf management 10.10.10.10

The CSV remains simple, while the tool handles the platform-specific command construction.
That is a small detail, but it is exactly the kind of detail that becomes annoying during operational work the more devices and VRFs involved, the more valuable this becomes.

3. SSH execution engine

The SSH layer opens an interactive shell, requests a pseudo-terminal and disables terminal paging with:

terminal length 0

This is important because command output must be collected completely, without pagination prompts interrupting the stream, the runner then sends each command and reads the output until the device prompt returns.
This approach is simple, but it also requires care, Cisco CLI output is not a clean API response it is terminal text and the collector needs to detect when the command has finished, strip the echoed command, remove the trailing prompt and write only the meaningful output.

The prompt detection logic is intentionally conservative, it looks for Cisco-like prompts ending in > or # at the end of the output, avoiding premature matches in the middle of command text.

Timeout handling is also important if a command hangs or takes too long, the session tries to recover by sending an interrupt, if recovery fails, the session is considered unhealthy and the caller should stop sending more commands to that device.
This is not glamorous code, but it is the kind of defensive logic that makes a small operational tool usable.

4. Structured output writer

The output writer creates a deterministic evidence tree.

Example:

output/
└── 2026-06-19T12-30-00Z/
    └── DC1/
        └── ROOM-A/
            └── CORE/
                └── leaf01/
                    ├── show_version.txt
                    ├── show_interface_status.txt
                    └── specialized/
                        └── ping_vrf_management_10_10_10_10.txt

This is more than cosmetic.
A structured folder tree makes it easier to:

compare pre-check and post-check outputs
share results with colleagues
archive migration data
support troubleshooting and RCA activities
understand which device produced which output

The filenames are sanitized so commands become filesystem-safe text files, again, simple detail, big operational value.

Where AI fits and where it should not

This project also raises an interesting question, in the AI era, why write a deterministic command collector at all can we ask AI to connect directly to the devices?

Answer is NO, AI and automations solve different problems.

AI is excellent for:

helping design the tool
reviewing code
explaining trade-offs
generating documentation
creating test cases
suggesting edge cases
helping non-developers understand the workflow
converting operational notes into structured CSV drafts
summarizing collected outputs after execution

But I would be very careful about using AI as the direct execution layer for network changes or production command collection without strict boundaries.

During a migration, I do not want a probabilistic system deciding what to execute on a device and potentially drift or reprocess with the risk of altering the data output.

I want deterministic input
I want human review
I want predictable execution
I want repeatable output that happen blazing fast at zero cost
I want an artifact that can be stored and audited later

This is where a simple program has play a strategic role, the CSV file defines intent in a deterministic way, the Go binary executes exactly what was declared, the output folder stores the evidence.
AI can help around the workflow or to answer quickly some question or clarify doubts later, but it should not blur the execution contract.

In other words AI is useful as an assistant, the automation engine must remain deterministic, this distinction is very important for me.
AI can help us move faster, but it should not make operational execution less explainable.

Simplicity is not the opposite of engineering

There is a common mistake in technical environments: assuming that simple tools are less serious. I believe the opposite is true, a simple tool can be the result of very deliberate engineering decisions.

In this case, the decisions were:

use CSV because the team can review it
use Go because the result can be distributed as a binary
use SSH because the devices already expose CLI access
write text files because they are easy to archive and compare
keep the scope narrow because the goal is operational reliability
avoid framework dependency because the environment is managed
avoid AI-driven execution because the task requires determinism

This approach is not anti-framework, anti-AI, or anti-Python. It is simply about choosing the right level of abstraction for the specific problem at hand.

When I would still choose Ansible, Python or a framework

I would not use Cisco Go Collector for everything. I would still choose Ansible, Python, Nornir, pyATS, or a comprehensive framework when I need:

complex workflows
configuration deployment
idempotency
reusable automation roles
source-of-truth integration
structured parsing
compliance checks
CI/CD pipelines
test-driven network validation
multi-vendor abstraction
API-first automation
long-term automation platform governance

Those are valid, essential use cases. But for quick, repeatable, human-reviewable command collection during a migration window, a small deterministic collector is a much better operational fit.

A simple decision model

The conversation should not be "framework vs. no framework." the real question is: what is the smallest reliable automation model that solves the operational problem without creating unnecessary friction?

Here is a practical decision matrix:

Scenario	Better fit
One-time or repeated command collection	Small collector
Migration pre/post checks	Small collector
Evidence capture for RCA	Small collector
Non-developer operators involved	Small collector
Locked-down workstation environment	Small collector
Desired-state configuration management	Ansible / framework
Complex orchestration	Ansible / Nornir / Python
Structured validation and parsing	pyATS / Python
Platform governance and reusable roles	Automation platform
Natural language explanation and documentation	AI assistant
Production execution decisions	Deterministic automation

This is not a competition between tools, it is a matter of operational fit.

The strategic role of boring automation

The more I work in complex infrastructure environments, the more I appreciate boring automation.

Boring automation is predictable, it is reviewable, it is easy to explain, it survives change windows and it does not require everyone on the team to learn a new ecosystem. Sometimes, boring automation is exactly what allows a team to move faster.

Cisco Go Collector is intentionally small. It does not try to become a super big project, it simply solves a real operational problem: run declared Cisco CLI commands in an easy way and collect the outputs in an organized way.

That simplicity is not a weakness, it is the core feature.

Love to hear from your experience

I believe the future of infrastructure automation will not only be about bigger platforms, AI agents, or higher abstraction. Those things will matter, but there will also be an increasing need for small, deterministic, portable tools that solve specific operational problems with zero friction.

Especially in large corporate environments, the best technical solution is not always the most sophisticated one. The best automation is the one your colleagues can actually run, understand, review, and trust.

That is where simplicity becomes strategic.
What is your favorite piece of "boring automation"? Let me know in the comments!

Ciao from Italy
Tia

I got tired of copying ping, traceroute, MTR and port checks so I built pingtrace

Tia Zanella — Tue, 16 Jun 2026 10:07:31 +0000

I built https://github.com/skhell/pingtrace because network troubleshooting is rarely about one single command.

It usually starts simple, someone says the service XYZ is not reachable.

Then the real work begins.

You ping the target.
You run traceroute or tracert.
You maybe run MTR.
You check DNS.
You check whether the service port is reachable.
You copy outputs into notes.
You repeat the same thing for another host, then another subnet, then another environment.
Finally, you try to turn all of that into evidence for a ticket, incident report, handover or RCA.
And for public IPs? I let you imagine.

The problem is not that ping or traceroute are hard.
The problem is the context switching.

https://github.com/skhell/pingtrace is my attempt to reduce that friction.

What pingtrace is

https://github.com/skhell/pingtrace is a terminal-first CLI for rapid network troubleshooting.

It combines several common checks into one workflow:

ping
traceroute / tracert depending on the operating system
MTR-style probing
TCP service reachability checks without nmap or root access
reverse DNS enrichment
optional ipinfo.io enrichment
optional PeeringDB enrichment
CSV export
JSON export
multiple targets
CIDR ranges
input from file

The idea is very simple

get a clean, readable and exportable view of reachability, path and service availability in one run.

It is not meant to replace the standard tools.

I still trust ping, traceroute, mtr and still use specialized tools when I need them.
https://github.com/skhell/pingtrace sits in the middle: a practical wrapper for the troubleshooting workflow I see repeat constantly.

The workflow problem

During incidents, the technical check is only half of the job, the other half is communication.
You need to explain what you tested, from where, against which target, with what result.

For example:

Was ICMP reachable if not blocked by firewall?
Did the path complete?
Where did the trace stop?
Did DNS resolve?
Was TCP/443 reachable?
Was TCP/22 reachable?
Was the issue isolated to one host or a range?
Can I attach the output to a ticket?
Can someone else read the result without guessing what I did?
Can you handoff to the night shift to follow troubleshooting?

That is where raw terminal output becomes messy, one command is fine, while twenty terminal windows during a live incident are not.

This type of workflow is very similar when you want a "before and after" that preceed and succeed a migration.

pingtrace basic examples

Run ping and trace against one target:

pingtrace 1.1.1.1

Run MTR mode:

pingtrace 1.1.1.1 --mtr

Run bounded MTR and export the result:

pingtrace 1.1.1.1 --mtr --cycles 10 --interval 2 --export ./reports

Run against multiple targets:

pingtrace 1.1.1.1,8.8.8.8,example.com

Run against a CIDR:

pingtrace 10.0.0.0/30

Run from a file:

pingtrace --file ./targets.csv

Export CSV and JSON evidence:

pingtrace 1.1.1.1 --export ./reports --json

TCP service reachability without nmap and root/admin

The latest improvement adds TCP service reachability checks.

Example:

pingtrace 10.0.0.1 --ports 22,80,443

Against a small CIDR:

pingtrace 10.0.0.0/28 --ports 22,80,443 --export ./reports

Or all ports:

pingtrace 10.0.0.1 --ports

This uses TCP connect behavior and that matters because it does not require root/admin privileges.

No raw sockets.
No privileged execution.
No special setup for the common troubleshooting case.

It also enriches known ports with IANA service names where possible.
This is not intended to replace nmap or masscan.

Those tools are excellent and much deeper, my purpose here is again different and simple.

pingtrace --ports is for fast operational reachability checks:

Can this client reach this TCP service from here?

That question appears constantly in real infrastructure work.

Enrichment with DNS ipinfo.io and PeeringDB

Troubleshooting is easier when the output gives context, an IP address alone is not always enough and https://github.com/skhell/pingtrace can enrich results with:

reverse DNS
private DNS for internal environments
public DNS
ipinfo.io data
PeeringDB context

This is useful when looking at public paths, carrier hops, cloud networks, content networks or peering-related information.
Private and public addresses are handled differently, because internal infrastructure should not be treated like Internet routing data.

The goal is not to make assumptions, the goal is to give the engineer more context in the same output.

Export matters

I care a lot about export quality and standardization because troubleshooting does not end in the terminal.

Sooner or later, someone asks:

Can you send me the evidence? or Can you attach the result to the incident? or Can we use this in the RCA?

https://github.com/skhell/pingtrace can export CSV and JSON reports.

Example:

pingtrace app.example.com --export ./incident-123 --json

For a TCP reachability check:

pingtrace app.example.com --ports 80,443 --export ./incident-123

For a small subnet:

pingtrace 10.0.12.0/28 --ports 22,80,443 --export ./incident-123

This makes the tool useful not only for interactive troubleshooting, but also for documentation and team handover.

What pingtrace is not

I want to keep the scope honest.

https://github.com/skhell/pingtrace is not:

a replacement for nmap
a replacement for full observability
a packet analyzer
a vulnerability scanner
a network monitoring platform
a magic root cause engine

It is a focused CLI for reachability, path visibility, TCP service checks, enrichment and export, that focus matters.
Many tools become less useful when they try to become everything.

I want https://github.com/skhell/pingtrace to stay clean and practical.

Who it is for

I am building https://github.com/skhell/pingtrace for people who actually troubleshoot and plan infrastructure changes or migration:
The best use case is when you need a fast answer and a clean repeatable artifacts.

Not just:

Is it reachable?

But also:

Can I show what I tested in a clean standardized format?

Example incident flow

A simple workflow could look like this:

mkdir incident-456

pingtrace app.example.com --mtr --cycles 10 --interval 2 --export ./incident-456 --json

pingtrace app.example.com --ports 80,443 --export ./incident-456

pingtrace 10.0.12.0/28 --ports 22,80,443 --export ./incident-456

At the end, I have a directory with evidence I can reuse and help team understanding the scope to later go deeper with Wireshark or specialized software/tools. That is the kind of boring operational detail that matters during real incidents addressing fast answers.

What comes next

The direction I want for https://github.com/skhell/pingtrace is clear:

better troubleshooting evidence
better exports with IEEE oui integration
cleaner output
standardization improvements
no unnecessary privileges great in enterprise environments
practical workflows for real infrastructure teams

I am not trying to build a flashy tool, I am trying to build something I would actually use under pressure.

Feedback wanted

If you work in networking, cloud, SRE, infrastructure support or incident response, I would really appreciate feedback.
The most useful feedback is not only "nice project", the most useful feedback is:

this output field is missing
this flag is confusing
this workflow does not match reality
this would help during RCA
this should stay out of scope
this would make it easier for a team to adopt

GitHub: https://github.com/skhell/pingtrace

If it saves time in one troubleshooting session, it was worth building.

OSIRIS JSON Producer for Cisco

Tia Zanella — Fri, 10 Apr 2026 12:00:00 +0000

The OSIRIS JSON Cisco producer connects to Cisco infrastructure platforms (APIC, NX-OS, IOS-XE) and generates OSIRIS JSON snapshots of your network topology, devices, interfaces, and connections.

Install the core dispatcher and the Cisco producer:

go install go.osirisjson.org/producers/cmd/osirisjson-producer@latest
go install go.osirisjson.org/producers/cmd/osirisjson-producer-cisco@latest

The core dispatcher lets you run osirisjson-producer cisco .... Without it, invoke the vendor binary directly as osirisjson-producer-cisco ....

Make sure $GOPATH/bin (or $HOME/go/bin) is in your PATH. See the getting started page for more install options.

Supported platforms

    ACI / APIC

    available

  Application Policy Infrastructure Controller

  Transport: REST API




    NX-OS

    available

  Nexus data center switches

  Transport: NX-API CLI




    IOS-XE

    available

  Enterprise routers and switches

  Transport: NETCONF/YANG over SSH

CLI usage

The Cisco producer uses a dispatcher-style CLI with sub-producers:

osirisjson-producer cisco <subcommand> [flags]

Single mode

Connect to one device and save an OSIRIS JSON document as cisco-<type>-<timestamp>-<hostname>.json:

# ACI fabric snapshot via APIC
osirisjson-producer cisco apic -h 10.0.0.1 -u admin -p secret

# NX-OS device snapshot
osirisjson-producer cisco nxos -h switch01.example.com -u admin -p secret

# IOS-XE device snapshot
osirisjson-producer cisco iosxe -h router01.example.com -u admin --insecure

If -p / --password is omitted, the CLI prompts interactively.

Batch mode

Collect from multiple devices listed in a CSV file. Output is organized as a hierarchical directory structure: DC/Floor/Room/Zone/Hostname.json.

osirisjson-producer cisco apic -s datacenter.csv -o ./output -u admin -p secret

Generate a CSV template to get started:

osirisjson-producer cisco template --generate apic

The CSV template uses these columns:

Column	Required	Description
`dc`		Datacenter name (used for output folder hierarchy)
`floor`		Floor identifier
`room`		Room identifier
`zone`		Zone or pod identifier
`hostname`	yes	Device label used as output filename
`type`	yes	Producer type: `apic`, `nxos`, `iosxe`
`ip`	yes	IP address or FQDN of the target device
`port`		Override port (default: producer-specific)
`owner`		`self` (default), `isp`, or `colo` - operator metadata only
`notes`		Free-text notes (ignored by producer)

Credentials are provided via -u/-p flags and apply to all targets in the batch.

Flags reference

Single mode flags

Flag	Short	Description
`--host`	`-h`	Target host (IP or FQDN, optionally with `:port`)
`--username`	`-u`	Username for authentication
`--password`	`-p`	Password (omit for interactive prompt)
`--port`	`-P`	Override port (default: producer-specific)
`--detail`		Detail level: `minimal` (default) or `detailed`
`--insecure`		Skip TLS certificate verification
`--safe-failure-mode`		Secret handling: `fail-closed` (default), `log-and-redact`, `off`

Batch mode flags

Flag	Short	Description
`--source`	`-s`	CSV file with targets
`--output`	`-o`	Output directory (hierarchical: `DC/Floor/Room/Zone/Hostname.json`)
`--username`	`-u`	Default username for all targets
`--password`	`-p`	Default password for all targets

Global flags

Flag	Description
`--version` / `-v`	Display version and exit
`--help`	Display help and exit

What each platform collects

ACI / APIC

The APIC producer queries the following MO classes via the REST API:

Minimal mode:

MO Class	Description
`fabricNode`	Fabric nodes (controllers, spines, leafs)
`topSystem`	System attributes (uptime, state, fabric MAC, control plane MTU)
`firmwareRunning`	Running firmware versions
`fvTenant`	Tenant definitions
`fvCtx`	VRF contexts
`fvBD`	Bridge domains
`fvSubnet`	Subnets
`fvAEPg`	Application endpoint groups
`l3extOut`	L3 external connectivity
`faultInst`	Active fault instances

Detailed mode adds:

MO Class	Description
`fvCEp`	Client endpoints (MAC, VLAN encap, leaf attachment)

NX-OS

The NX-OS producer sends NX-API CLI commands in batched requests:

Minimal mode:

Command	Description
`show version`	Device model, serial number, OS version, uptime
`show inventory`	Hardware inventory (modules, power supplies, fans)
`show interface brief`	Interface names, states, speeds, VLANs
`show vlan brief`	VLAN IDs, names, and member interfaces
`show vrf all detail`	VRF definitions and member interfaces
`show lldp neighbors detail`	LLDP neighbor discovery
`show vpc brief`	vPC domain, peer status, keepalive
`show port-channel summary`	Port-channel configurations

Detailed mode adds:

Command	Description
`show interface`	Full interface stats (MTU, bandwidth, duplex, counters)
`show system resources`	CPU idle %, memory usage, load averages
`show environment`	Power supplies, fan status, temperatures

IOS-XE

The IOS-XE producer uses NETCONF/YANG RPCs over SSH (default port 830):

Minimal mode:

YANG Model	Description
`Cisco-IOS-XE-native`	Device version and hostname
`ietf-interfaces`	Interface details
`Cisco-IOS-XE-device-hardware-oper`	Hardware inventory
`Cisco-IOS-XE-cdp-oper`	CDP neighbor discovery
`Cisco-IOS-XE-native (vrf)`	VRF definitions

Detailed mode adds:

YANG Model	Description
`Cisco-IOS-XE-bgp-oper`	BGP neighbor details
`Cisco-IOS-XE-ospf-oper`	OSPF process and neighbor state
`Cisco-IOS-XE-process-cpu-oper`	CPU utilization
`Cisco-IOS-XE-memory-oper`	Memory statistics

OSIRIS JSON output structure

All three producers emit the same OSIRIS JSON envelope:

{
  "$schema": "https://osirisjson.org/schema/v1.0/osiris.schema.json",
  "version": "1.0.0",
  "metadata": {
    "generator": {
      "name": "osirisjson-producer-cisco-<platform>",
      "version": "0.1.0"
    },
    "scope": {
      "providers": ["cisco"]
    }
  },
  "topology": {
    "resources": [ ... ],
    "connections": [ ... ],
    "groups": [ ... ]
  }
}

Resource types by platform

Resource types follow the OSIRIS JSON v1.0 specification. Standard types are used where defined; vendor-specific types use the osiris.cisco.* namespace.

IOS-XE:

network.router - Primary device (standard)
network.interface - Physical and logical interfaces (standard)
osiris.cisco.interface.lag - Port-channel / LAG interfaces

NX-OS:

osiris.cisco.switch.spine / osiris.cisco.switch.leaf - Device (role-classified)
network.interface - Physical and logical interfaces (standard)
osiris.cisco.interface.lag - Port-channels

APIC:

osiris.cisco.controller - APIC controllers
osiris.cisco.switch.spine / osiris.cisco.switch.leaf - Fabric switches
osiris.cisco.domain.bridge - Bridge domains
network.subnet - Subnets (standard)
osiris.cisco.l3out - L3 external networks
osiris.cisco.endpoint - Client endpoints (detailed mode only)

Connection types

IOS-XE / NX-OS: physical.ethernet for CDP/LLDP-discovered links between interfaces
APIC: contains for tenant hierarchy containment, network for bridge domain associations

Group types by platform

IOS-XE: logical.vrf

NX-OS: logical.vrf, network.vlan, network.vpc

APIC: logical.tenant, logical.vrf, osiris.cisco.epg

Connection discovery

IOS-XE discovers neighbors via CDP (Cisco Discovery Protocol)
NX-OS discovers neighbors via LLDP (Link Layer Discovery Protocol)
APIC uses containment hierarchy (tenants -> BDs -> subnets -> EPGs) rather than point-to-point links

Remote devices discovered via CDP/LLDP are added as stub resources with status: unknown.

Examples

IOS-XE - single device, minimal mode

osirisjson-producer cisco iosxe -h 10.99.0.1 -u admin -p secret

Output (trimmed):

{
  "$schema": "https://osirisjson.org/schema/v1.0/osiris.schema.json",
  "version": "1.0.0",
  "metadata": {
    "generator": {
      "name": "osirisjson-producer-cisco-iosxe",
      "version": "0.1.0"
    },
    "scope": {
      "providers": ["cisco"]
    }
  },
  "topology": {
    "resources": [
      {
        "id": "cisco-iosxe-LAB-RTR01",
        "type": "network.router",
        "name": "LAB-RTR01",
        "status": "active",
        "provider": {
          "name": "cisco",
          "type": "ISR4451-X/K9",
          "version": "16.9"
        },
        "extensions": {
          "osiris.cisco": {
            "inventory": [
              { "name": "Chassis", "description": "ISR4451-X/K9", "serial": "FDO12345678" }
            ]
          }
        }
      },
      {
        "id": "cisco-iosxe-LAB-RTR01-GigabitEthernet0/0/0",
        "type": "network.interface",
        "name": "GigabitEthernet0/0/0",
        "status": "active",
        "properties": {
          "speed": "1000000000",
          "description": "WAN uplink"
        }
      }
    ],
    "connections": [
      {
        "source": "cisco-iosxe-LAB-RTR01-GigabitEthernet0/0/0",
        "target": "cisco-iosxe-stub-REMOTE-SW01-GigabitEthernet1/0/1",
        "type": "physical.ethernet",
        "status": "active"
      }
    ],
    "groups": [
      {
        "id": "cisco-iosxe-LAB-RTR01-vrf-CORP",
        "type": "logical.vrf",
        "name": "CORP",
        "members": [
          "cisco-iosxe-LAB-RTR01-GigabitEthernet0/0/0",
          "cisco-iosxe-LAB-RTR01-Loopback0"
        ]
      }
    ]
  }
}

NX-OS - single device, detailed mode

osirisjson-producer cisco nxos -h switch01.lab -u admin -p secret --detail detailed

Output (trimmed):

{
  "$schema": "https://osirisjson.org/schema/v1.0/osiris.schema.json",
  "version": "1.0.0",
  "metadata": {
    "generator": {
      "name": "osirisjson-producer-cisco-nxos",
      "version": "0.1.0"
    },
    "scope": {
      "providers": ["cisco"]
    }
  },
  "topology": {
    "resources": [
      {
        "id": "cisco-nxos-LAB-SW01",
        "type": "osiris.cisco.switch.leaf",
        "name": "LAB-SW01",
        "status": "active",
        "provider": {
          "name": "cisco",
          "type": "Nexus9000 C9508",
          "version": "10.3(4a)"
        },
        "extensions": {
          "osiris.cisco": {
            "bios_version": "08.40",
            "kernel_uptime": "15d 3h 22m 10s",
            "cpu_idle": 85.5,
            "load_avg_1min": 1.23,
            "memory_used": 8192,
            "memory_free": 24576,
            "power_supplies": [
              { "id": "1", "model": "NXA-PAC-1100W", "watts": 350, "status": "ok" }
            ],
            "fans": [
              { "name": "Fan1", "status": "ok" }
            ],
            "temperatures": [
              { "sensor": "SUP slot 1", "celsius": 35.5 }
            ]
          }
        }
      },
      {
        "id": "cisco-nxos-LAB-SW01-Ethernet1/1",
        "type": "network.interface",
        "name": "Ethernet1/1",
        "status": "active",
        "properties": {
          "speed": "10000000000",
          "description": "Server-facing"
        }
      }
    ],
    "connections": [
      {
        "source": "cisco-nxos-LAB-SW01-Ethernet1/1",
        "target": "cisco-nxos-stub-REMOTE-SW01-Ethernet1/49",
        "type": "physical.ethernet",
        "status": "active"
      }
    ],
    "groups": [
      {
        "id": "cisco-nxos-LAB-SW01-vlan-100",
        "type": "network.vlan",
        "name": "PROD",
        "members": ["cisco-nxos-LAB-SW01-Ethernet1/1"]
      },
      {
        "id": "cisco-nxos-LAB-SW01-vpc-10",
        "type": "network.vpc",
        "name": "vPC domain 10",
        "extensions": {
          "osiris.cisco": {
            "role": "primary",
            "peer_status": "peer-ok",
            "keepalive_status": "peer-alive"
          }
        }
      }
    ]
  }
}

APIC - ACI fabric snapshot

osirisjson-producer cisco apic -h 10.0.0.1 -u admin -p secret --detail detailed

Output (trimmed):

{
  "$schema": "https://osirisjson.org/schema/v1.0/osiris.schema.json",
  "version": "1.0.0",
  "metadata": {
    "generator": {
      "name": "osirisjson-producer-cisco-apic",
      "version": "0.1.0"
    },
    "scope": {
      "providers": ["cisco"]
    }
  },
  "topology": {
    "resources": [
      {
        "id": "cisco-apic-apic1",
        "type": "osiris.cisco.controller",
        "name": "apic1",
        "status": "active",
        "provider": {
          "name": "cisco",
          "type": "APIC-SERVER-M3",
          "version": "6.0(2h)",
          "site": "pod-1"
        }
      },
      {
        "id": "cisco-apic-spine1",
        "type": "osiris.cisco.switch.spine",
        "name": "spine1",
        "status": "active",
        "provider": {
          "name": "cisco",
          "type": "N9K-C9336C-FX2",
          "version": "n9000-16.0(2h)",
          "site": "pod-1"
        },
        "extensions": {
          "osiris.cisco": {
            "fabric_mac": "AA:BB:CC:DD:EE:01",
            "control_plane_mtu": 9000,
            "faults": [
              { "code": "F1527", "severity": "warning", "description": "storage full" }
            ]
          }
        }
      },
      {
        "id": "cisco-apic-bd-bd_App",
        "type": "osiris.cisco.domain.bridge",
        "name": "bd_App",
        "status": "active"
      },
      {
        "id": "cisco-apic-subnet-10.0.0.1/24",
        "type": "network.subnet",
        "name": "10.0.0.1/24",
        "status": "active"
      },
      {
        "id": "cisco-apic-ep-AA:BB:CC:DD:EE:FF",
        "type": "osiris.cisco.endpoint",
        "name": "AA:BB:CC:DD:EE:FF",
        "status": "active",
        "properties": {
          "encap": "vlan-100",
          "leaf": "leaf1",
          "interface": "eth1/1"
        }
      }
    ],
    "groups": [
      {
        "id": "cisco-apic-tenant-tn_Example",
        "type": "logical.tenant",
        "name": "tn_Example",
        "children": [
          "cisco-apic-vrf-tn_Example-vrf_Main",
          "cisco-apic-epg-tn_Example-epg_WEB"
        ]
      },
      {
        "id": "cisco-apic-vrf-tn_Example-vrf_Main",
        "type": "logical.vrf",
        "name": "vrf_Main"
      },
      {
        "id": "cisco-apic-epg-tn_Example-epg_WEB",
        "type": "osiris.cisco.epg",
        "name": "epg_WEB",
        "members": ["cisco-apic-ep-AA:BB:CC:DD:EE:FF"]
      }
    ]
  }
}

Batch mode - multi-device collection

Create a CSV inventory file:

dc,floor,room,zone,hostname,type,ip,port,owner,notes
AMS-01,F3,R301,POD-A,apic-01,apic,10.10.1.1,,self,Primary controller
AMS-01,F3,R301,POD-A,nx-spine-01,nxos,10.10.1.10,,self,Spine switch
AMS-01,F3,R302,POD-B,xe-router-01,iosxe,172.16.0.1,,isp,PE router

Run the batch:

osirisjson-producer cisco apic -s inventory.csv -o ./output -u admin -p secret

The resulting output directory:

output/
  AMS-01/
    F3/
      R301/
        POD-A/
          apic-01.json
          nx-spine-01.json
      R302/
        POD-B/
          xe-router-01.json

Source: https://osirisjson.org/en/docs/producers/network/cisco

OSIRIS JSON Producer for Microsoft Azure

Tia Zanella — Wed, 08 Apr 2026 07:54:58 +0000

The OSIRIS JSON Azure producer connects to Microsoft Azure via the Azure CLI (az) and generates OSIRIS JSON snapshots of your subscription topology - virtual networks, subnets, NICs, NSGs, load balancers, firewalls, VMs, and more.

To begin using OSIRIS JSON for Microsoft Azure, install the core dispatcher and the Azure producer:

go install go.osirisjson.org/producers/cmd/osirisjson-producer@latest
go install go.osirisjson.org/producers/cmd/osirisjson-producer-azure@latest

The core dispatcher lets you run osirisjson-producer azure .... Without it, invoke the vendor binary directly as osirisjson-producer-azure ....

Make sure $GOPATH/bin (or $HOME/go/bin) is in your PATH. See the getting started page for more install options.

Prerequisites

Install the Azure CLI
Authenticate: az login
The authenticate user must have a read permission to one or multiple target subscriptions, you can execute the producer on your local machine or decide to invoke the producer using a scheduled job using a service account with your favourite software or platform.

CLI usage

osirisjson-producer azure [flags]
osirisjson-producer azure template --generate

Single mode

Start by collecting one subscription that will be automatically saved as microsoft-azure-<timestamp>-<name>.json:

osirisjson-producer azure -S a1b2c3d4-e5f6-7890-abcd-ef1234567890

Interactive mode

Run without flags to get an interactive subscription picker:

osirisjson-producer azure

The producer discovers all accessible subscriptions and presents a numbered list. Select one or more (comma-separated) or type all.

Multi-subscription mode

Collect multiple subscriptions to an output directory:

# Specific subscriptions
osirisjson-producer azure -S sub-id-1,sub-id-2,sub-id-3 -o ./output

# All accessible subscriptions (auto-discover)
osirisjson-producer azure --all -o ./output

# All subscriptions in a specific tenant
osirisjson-producer azure --all --tenant f1e2d3c4-b5a6-9078-fedc-ba9876543210 -o ./output

Batch mode (CSV)

Generate a CSV template:

osirisjson-producer azure template --generate

Collect from a CSV file:

osirisjson-producer azure -s subscriptions.csv -o ./output

The CSV template uses these columns:

Column	Required	Description
`subscription_id`	yes	Azure subscription UUID
`subscription_name`	yes	Human-readable label (used as output filename)
`tenant_id`		Azure AD / Entra ID tenant UUID
`environment`		Deployment stage: `dv`, `np`, `pr` (development, non-production, production)
`region`		Filter to Azure region (empty = all regions)
`notes`		Free-text notes (ignored by producer)

Output hierarchy

Single mode: saves to microsoft-azure-<timestamp>-<name>.json in the current directory.

Multi/batch/all modes: organized by tenant and timestamp:

output/
  <TenantID>/
    <timestamp>/
      <SubscriptionName>.json

Each subscription produces a self-contained OSIRIS document. Cross-subscription references (e.g. VNet peerings to remote subscriptions) use deterministic resource IDs that consumers can correlate across documents.

Multi-tenant environments

Run the producer once per tenant. Each az login authenticates to one tenant. Use az login --tenant <tenant-id> to switch. The output hierarchy groups documents by tenant automatically.

Flags reference

Flag	Short	Description
`--subscription`	`-S`	Azure subscription ID(s), comma-separated
`--all`		Auto-discover all accessible subscriptions
`--source`	`-s`	CSV file with subscription targets
`--output`	`-o`	Output directory (required for multi/all/CSV mode)
`--tenant`		Azure AD / Entra ID tenant ID (optional)
`--region`		Filter to a specific Azure region (optional)
`--detail`		Detail level: `minimal` (default) or `detailed`
`--safe-failure-mode`		Secret handling: `fail-closed` (default), `log-and-redact`, `off`
`--version` / `-v`		Display version and exit
`--help`		Display help and exit

What it collects

The Azure producer queries the following resource types via the Azure CLI:

Minimal mode:

Azure Resource Type	OSIRIS Type	Description
Virtual Networks	`network.vpc`	VNets with address space, DNS, peerings
Subnets	`network.subnet`	Subnets with address prefixes, service endpoints
Network Interfaces	`network.interface`	NICs with IP configurations
Network Security Groups	`network.security.group`	NSGs with rule summaries
Route Tables	`osiris.azure.routetable`	UDRs with route counts
Public IP Addresses	`osiris.azure.publicip`	Public IPs with allocation method
Load Balancers	`network.loadbalancer`	L4 load balancers
Application Gateways	`network.loadbalancer`	L7 load balancers (app gateways)
Private Endpoints	`osiris.azure.privateendpoint`	Private link endpoints
VNet Gateways	`osiris.azure.gateway.vnet`	ExpressRoute / VPN gateways
NAT Gateways	`osiris.azure.gateway.nat`	Outbound NAT gateways
Azure Firewalls	`network.firewall`	Azure Firewall instances
DNS Zones	`osiris.azure.dns.zone`	Public DNS zones
Private DNS Zones	`osiris.azure.dns.privatezone`	Private DNS zones with VNet links
ExpressRoute Circuits	`osiris.azure.expressroute`	ExpressRoute circuits
Virtual Machines	`compute.vm`	VMs with size, power state
Resource Groups	`container.resourcegroup`	Resource groups as container resources

Detailed mode adds route table route details, load balancer rules, and extended properties.

OSIRIS JSON output structure for Microsoft Azure

{
  "$schema": "https://osirisjson.org/schema/v1.0/osiris.schema.json",
  "version": "1.0.0",
  "metadata": {
    "generator": {
      "name": "osirisjson-producer-azure",
      "version": "0.1.0"
    },
    "scope": {
      "providers": ["azure"],
      "accounts": ["<tenant-id>"],
      "subscriptions": ["<subscription-id>"],
      "regions": ["westeurope", "eastus"]
    }
  },
  "topology": {
    "resources": [ ... ],
    "connections": [ ... ],
    "groups": [ ... ]
  }
}

Resource types

Resource types follow the OSIRIS JSON v1.0 specification. Standard types are used where defined; Azure-specific types use the osiris.azure.* namespace.

Standard types:

container.resourcegroup - Resource groups
network.vpc - Virtual networks
network.subnet - Subnets
network.interface - Network interfaces
network.security.group - Network security groups
network.loadbalancer - Load balancers (L4 and L7)
network.firewall - Azure Firewalls
compute.vm - Virtual machines

Custom types (osiris.azure.*):

osiris.azure.routetable - Route tables
osiris.azure.publicip - Public IP addresses
osiris.azure.privateendpoint - Private endpoints
osiris.azure.gateway.vnet - VNet gateways (VPN/ExpressRoute)
osiris.azure.gateway.nat - NAT gateways
osiris.azure.dns.zone - DNS zones
osiris.azure.dns.privatezone - Private DNS zones
osiris.azure.expressroute - ExpressRoute circuits

Connection types

network - Network connectivity (VNet peerings, NIC-to-subnet, NSG associations, DNS links, gateway connections)
contains - Containment (subnet-to-VNet membership)

Group types

logical.subscription - Top-level subscription group
logical.resourcegroup - Resource group groups (children of subscription)

Provider metadata

Every resource includes provider.type with the native ARM resource type (e.g. Microsoft.Network/virtualNetworks, Microsoft.Compute/virtualMachines). Cross-subscription peering stubs include provider.subscription with the remote subscription ID.

Resource IDs

Azure resource IDs follow the pattern azure::<ARM-resource-id>, using the full ARM resource ID as the native identifier. This ensures globally unique, deterministic IDs.

Examples

Single subscription

We are going to explore a single subscription in our tenant and generate from Microsoft Azure an OSIRIS JSON document.

osirisjson-producer azure -S a1b2c3d4-e5f6-7890-abcd-ef1234567890

OSIRIS JSON output document (trimmed):

{
  "$schema": "https://osirisjson.org/schema/v1.0/osiris.schema.json",
  "version": "1.0.0",
  "metadata": {
    "generator": {
      "name": "osirisjson-producer-azure",
      "version": "0.1.0"
    },
    "scope": {
      "providers": ["azure"],
      "accounts": ["f1e2d3c4-b5a6-9078-fedc-ba9876543210"],
      "subscriptions": ["a1b2c3d4-e5f6-7890-abcd-ef1234567890"],
      "regions": ["westeurope"]
    }
  },
  "topology": {
    "resources": [
      {
        "id": "azure::/subscriptions/a1b2c3d4/resourceGroups/network-rg/providers/Microsoft.Network/virtualNetworks/hub-vnet",
        "type": "network.vpc",
        "name": "hub-vnet",
        "status": "active",
        "provider": {
          "name": "azure",
          "native_id": "/subscriptions/a1b2c3d4/resourceGroups/network-rg/providers/Microsoft.Network/virtualNetworks/hub-vnet",
          "type": "Microsoft.Network/virtualNetworks",
          "region": "westeurope",
          "subscription": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
          "tenant": "f1e2d3c4-b5a6-9078-fedc-ba9876543210"
        },
        "properties": {
          "resource_group": "network-rg",
          "address_space": ["10.0.0.0/16"],
          "dns_servers": ["10.0.0.4"]
        }
      },
      {
        "id": "azure::/subscriptions/a1b2c3d4/resourceGroups/compute-rg/providers/Microsoft.Compute/virtualMachines/web-vm-01",
        "type": "compute.vm",
        "name": "web-vm-01",
        "status": "active",
        "provider": {
          "name": "azure",
          "native_id": "/subscriptions/a1b2c3d4/resourceGroups/compute-rg/providers/Microsoft.Compute/virtualMachines/web-vm-01",
          "type": "Microsoft.Compute/virtualMachines",
          "region": "westeurope",
          "subscription": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
          "tenant": "f1e2d3c4-b5a6-9078-fedc-ba9876543210"
        },
        "properties": {
          "resource_group": "compute-rg",
          "vm_size": "Standard_D2s_v3",
          "power_state": "VM running"
        }
      }
    ],
    "connections": [
      {
        "source": "azure::/subscriptions/a1b2c3d4/.../subnets/default",
        "target": "azure::/subscriptions/a1b2c3d4/.../virtualNetworks/hub-vnet",
        "type": "contains",
        "direction": "forward"
      }
    ],
    "groups": [
      {
        "id": "azure::subscription::a1b2c3d4-e5f6-7890-abcd-ef1234567890",
        "type": "logical.subscription",
        "name": "my-nonprod-subscription",
        "children": [
          "azure::resourcegroup::network-rg",
          "azure::resourcegroup::compute-rg"
        ]
      },
      {
        "id": "azure::resourcegroup::network-rg",
        "type": "logical.resourcegroup",
        "name": "network-rg",
        "members": [
          "azure::/subscriptions/a1b2c3d4/.../virtualNetworks/hub-vnet"
        ]
      }
    ]
  }
}

Source: https://osirisjson.org/en/docs/producers/hyperscalers/microsoft-azure

OSIRIS JSON a new journey beyond silos and tribal knowledge

Tia Zanella — Mon, 06 Apr 2026 15:23:44 +0000

Beyond the silos: The soul behind OSIRIS JSON

For twenty years, my mission has been to bridge the gap between siloed tribal knowledge and operational clarity. I’ve evolved from the manual era of painstakingly mapping fragmented topologies to building a solution that delivers a comprehensive, end-to-end snapshot of the infrastructure landscape. My goal building OSIRIS JSON is simple: to provide the big-picture visibility that empowers IT and OT professionals to make the right decisions with confidence.

In the world of infrastructure, we often settle for fragments. We see a server here, a cloud instance there, a facility sensor somewhere else. But my goal, no matter with who and for who I have been working for, has always been to achieve an end-to-end view of the entire infrastructure, seeing how every piece breathes together in one interconnected map, this for a very simple reason to achieve multiple goals:

eradicate silos, feudal thinking and critical context living in people heads embracing open standard Documentation as Code (Docs as Code) culture
providing an easy way for architects and IT/OT professionals to understand end-to-end the infrastructure in a fast up-to-date state in time
allowing fast troubleshooting maintaining a clear up-to-date infrastructure documentation and topology
allowing fast snapshot in time end-to-end of the infrastructure without complications or third-party scanning softwares making OSIRIS JSON a great allies under audit sessions
provide an accurate standardized baseline for LLMs allowing to understand the infrastructure landscape providing enhanced reasoning and automation

The human side of the infrastructure struggle

In December 2025 with a big ambition and a bit of crazyness I began writing the OSIRIS JSON Specification. It is the result of the experience gained by travelling, exploring, entertaining conversations to Senior Managers, IT/OT professionals, but also by getting closer and work with factory workers and their managers with whom I had a great opportunity to learn about different contexts that enriched me personally and helped shape the original idea by having the opportunity to see and understand that also this type of organization and visibility was lacking not just in the Information Technology area but also in the OT side under facility systems or in cross-scenarios and even in designing, maintaining, and sometimes failing within heterogeneous stacksfrom hyperscale public clouds to the complex, gritty intersections of IT and Facility OT.

Throughout this journey, I’ve encountered a recurring, deeply human problem: The impassable mountain of tribal knowledge. Some phrases everyone of us have been listening: Oh don’t touch that please we are aware it’s outdated but Karl made it and he left the company! Documentation is not important let’s focus on business needs or the false believe everything is fine All services are perfectly configured in Microsoft Azure nothing to be worried about. or you are called in an ARM or SBB approval meeting and somebody draw some lines in Microsoft Paint to represent the topology seeking for immediate approval because the stakeholders are in rush! Some weeks after when you are called to analyze with operations a major outage you discovered someone have misconfigured thing in the system architecture and you don’t know where to start troubleshoot because there is not accurate documentation or topology. All of us had or have a Karl in the organization.

We struggle against corporate silos that make a unified view feel nearly impossible!
We build bespoke, fragile integrations that break the moment a vendor changes their mind, and we know specially in IT this happen on a regular basis.

Even in scenarios where I produced rigorous documentation, the presence of team silos often meant that the “truth” of the infrastructure remained hidden or fragmented. I realized that if we can’t see our world, we can’t truly care for it making the right decisions with confidence.

I firmly believe that the clarity of systems infrastructure MUST NOT depend on who you are, who you know or which department you sit in. It is and MUST be a shared truth that belongs to everyone. - Tia Zanella - Founder and Lead Maintainer of OSIRIS JSON

What is OSIRIS JSON?

OSIRIS JSON is a vendor-neutral JSON interchange schema designed to be a universal language for infrastructure topology designed to include IT and OT environments.

Rather than wasting time and money developing every software integrations from scratch to learn a hundred different vendor-specific dialects, OSIRIS JSON separates the responsibilities:

The OSIRIS JSON producers translate the messy, fragmented data of the real world into a clean OSIRIS JSON document.
The OSIRIS JSON consumers read that document to provide a clear, point-in-time view of what exists and how it all relates. With the OSIRIS JSON document the consumers can produce topologies, diff, high quality automated documents and more.

A humble first step

In this first release, OSIRIS JSON is intentionally a static snapshot format. It is a “digital polaroid” of your infrastructure a moment in time. You can run directly from your notebook or in complex scenario demand it to an automation to produce scheduled results. It doesn’t try to do everything at once, but it provides something essential: a consistent foundation. By defining how resources and their relationships are documented regardless of team boundaries or vendor lock-in. In an open community culture we take the first step toward that end-to-end dream.

OSIRIS JSON is more than code; it is a perseverance commitment to transparency, high quality documentation and the firmly belief that even the most complex systems can be understood if we wear the right glasses. - Tia Zanella - Founder and Lead Maintainer of OSIRIS JSON

Visit: https://osirisjson.org/

Azure Boards CLI

Tia Zanella — Sat, 14 Mar 2026 09:21:35 +0000

npm i adoboards

If you feel like Homer Simpson backing into bushes right before sprint review, you are in the right place.

We've all been there. You're very busy into actual work and then someone reminds you that your user stories need descriptions, acceptance criteria, t-shirt sizes, and business value fields filled in before tomorrow's ceremony. The first time I heard "ceremony" I genuinely thought it was some kind of cult initiation.

Don't get me wrong Scrum and the job of Scam Masters are genuinely good when used properly. But let's be honest: most of us have seen it applied in ways that create more overhead than value, especially for architecture and infrastructure work where the real complexity lives in the system design, not in a Jira ticket template.

After nearly 20 years in the industry, I noticed something: the time spent writing and grooming work items is often disproportionate to the value they deliver. So inspired by git cli commands I built a tool to fix that.

adoboards is a CLI that pulls your Epics, Features, and User Stories from Azure DevOps Boards, organizes them locally as markdown files, and optionally lets AI handle the tedious writing for you.

If it saves you from one more sprint planning nightmare, it was worth building. Star the project on GitHub and feel free to leave a feedback.

pingtrace

Tia Zanella — Sat, 14 Mar 2026 09:16:56 +0000

npm i pingtrace

pingtrace is a terminal-first CLI designed for rapid network troubleshooting, combining ping and traceroute with a clear, intuitive output enriched by DNS and ipinfo.io data.

It runs ping and traceroute in a single command against:

Single target: Quick check for a single host.
Multi-target: Separate multiple targets with commas for simultaneous checks.
Bulk loading: Import target lists directly from CSV files.
CIDR blocks: Automatically check against IPv4 CIDR blocks.

The focus is simple: fast input, clear output, and optional CSV export.

If it saves you time from a troubleshooting session, it was worth building. Star the project on GitHub and feel free to leave feedbacks

OSIRIS a vendor-neutral JSON format for infrastructure snapshots (IT/OT)

Tia Zanella — Fri, 06 Feb 2026 08:02:51 +0000

After years of dealing with incompatible infra exports I created and published OSIRIS v1.0.0 a vendor-neutral JSON interchange format for point-in-time infrastructure snapshots and documentation: highlighting resources and their relationships (topology diagram), with an extension mechanism that can cover OT environments as well.

Project: https://osirisjson.org/

Schema: https://osirisjson.org/schema/v1.0/osiris.schema.json

Examples: https://osirisjson.org/docs/en/osiris-examples/01-it-infrastructure

The recurring problem

If you’ve ever tried to build tooling around infrastructure data (diagramming, inventory, audit, drift/diff, documentation), you’ve likely seen the same issue:

Every vendor exports data differently (even when it’s JSON).
Every tool ends up writing its own parsers and mappings, most of them if not all are closed source.
Relationships (what is connected to what, where it lives, how it depends) are the first thing that becomes inconsistent or implicit.
Over time, you either rebuild integrations repeatedly, or you rely on undocumented tribal knowledge that lives in people heads and most of time not so well organized so you receive vague answers to your infinite questions.

The result is fragmented, tool-specific pipelines that are expensive to maintain and cause you lot of pain to have a single point of view of the infrastructure.

What OSIRIS is

OSIRIS is a vendor-neutral JSON format for describing infrastructure resources and their topological relationships across heterogeneous IT and OT environments. OSIRIS generate a static snapshot interchange format.

A snapshot describes:

what exists (resources)
how it relates (connections / relationships)
at a specific time (point-in-time)

It is designed to be:

vendor-neutral (the schema is the contract)
tool-friendly (consumers don’t need vendor-specific parsers)
extensible (namespaced extensions for vendor or domain-specific fields, including OT)

What OSIRIS is not (in v1.0.0)

OSIRIS is not:

infrastructure-as-Code
configuration management
telemetry/metrics/streaming events

It’s a format you can export, validate, store, diff and consume.

Producer/Consumer split (the key idea)

Instead of every tool implementing every vendor format, OSIRIS separates responsibilities:

Producers translate source data into OSIRIS documents (hyperscalers or public cloud providers inventory APIs, network device outputs, OT gateways, CMDB exports, etc.)
Consumers read OSIRIS documents (diagram generators, inventory platforms, auditors, diff tools, documentation systems)

This keeps vendor-specific logic in one place and allows multiple tools to share the same snapshot format.

What’s included today

Specification & documentation: https://osirisjson.org/
Canonical core JSON Schema (v1.0): https://osirisjson.org/schema/v1.0/osiris.schema.json
Examples: https://osirisjson.org/docs/en/osiris-examples/01-it-infrastructure
A validation approach that starts with schema-level validation, leaving room for richer semantic validation later.

What I’d love feedback on

If you work with infra data, I’d appreciate critiques on:

1) Core model: Are “resources + relationships” sufficient and ergonomic for real topologies?

2) Extensibility: Is the extension/namespacing approach practical and future-proof?

3) Adoption path: Which first producer would be most useful to you (cloud inventory, device CLI, Terraform state, etc.)?

What’s next

I’m working on:

development guidelines for contributors
initial core/SDK work to make producers and consumers easier to build

If you want to review the spec/schema or suggest a first producer target, comments are welcome.

OSIRIS: https://osirisjson.org/

Net Commander: A Free Visual Studio Code Toolkit for Network Engineers

Tia Zanella — Mon, 26 May 2025 17:17:09 +0000

Hey network engineers and infrastructure enthusiasts! 👋

I’m excited to introduce Net Commander, an open-source project designed to simplify and supercharge your network troubleshooting and automation workflows—right from Visual Studio Code.

Visual Studio Code Marketplace

What is Net Commander?

Net Commander is a lightweight, modular Visual Studio Code extension that brings practical, day-to-day network tools right into your development and troubleshooting environment.

It’s built by a network engineer for network engineers and focuses on:

Guided Rootcause Analysis
WiFi analyzer (and more coming soon!)
CIDR calculations for quick subnetting
Ping utility with live response tracking
Traceroute topology visualization
PeeringDB integration for ASN and IX lookups
IANA port reference for fast port checks
RFC search with instant summaries

Why use Net Commander?

No more context-switching! Use network tools directly in your code editor

Export reports as CSV for compliance and documentation
Modular architecture for easy contributions and extensions
Open-source, MIT licensed—free to use and adapt for your needs

How to Get Started

Install the extension from Visual Studio Code Marketplace
Share feedback, ideas, or feature requests on GitHub Issues

Let’s Build It Together

Net Commander is evolving, and I’d love your input! 🚀 Whether you’re a network pro, a student, or someone curious about automation and troubleshooting, your contributions and feedback can make a difference.

Join the Community

If you find Net Commander useful, please consider starring the repo ⭐, sharing it with your team, or even contributing a feature or two. Let’s make networking easier, one module at a time!

Enhance Your TCP Troubleshooting: Free Wireshark Profile for Network Engineers

Tia Zanella — Mon, 26 May 2025 17:06:04 +0000

Hello, network engineers and packet enthusiasts! 🚀

I’m excited to share a Wireshark profile I’ve created to make TCP traffic analysis faster, clearer, and more intuitive. If you’ve ever spent hours digging through packet captures looking for TCP issues, you know how vital it is to have the right filters and visual cues at your fingertips.

What is this Wireshark profile?

This profile is tailored for network engineers working with TCP. It includes:

Custom display filters for key TCP flows (SYN, ACK, RST, retransmissions, etc.)
Coloring rules that visually highlight packet states and anomalies
A streamlined interface that saves time when troubleshooting slow connections, resets, or retransmission storms

You can preview the profile here:
https://github.com/elelabdev/wireshark-profile

Why use it?

This profile helps you:

Quickly isolate TCP session behaviors
Visually differentiate normal vs. abnormal packet patterns
Speed up troubleshooting for latency, drops, or packet loss
Learn and teach TCP concepts through visual cues

It’s a small tweak with a big impact when you’re working on complex network issues.

How to get started

Clone or download the profile from the GitHub repo
Import it into your Wireshark instance
Start capturing and see the difference in your packet analysis workflow!

Future plans

I’m always open to feedback. Have ideas for additional filters or color rules? Let’s collaborate!

Feel free to comment below, share your use cases, or contribute on GitHub. Let’s make TCP analysis smoother for everyone. 🚀