Core -> SCALE and LLDP

@pmh

Patrick, Thanks for the list.

I don’t remember the history with LLDP - I will review. Its a good observation that its more important for network admins than the storage admins. Is it worthwhile to make the package available and allow admin to set-up via CLI?

SNMP improvements - can you expand on specifics?
(it is true that we’ve invested in the API to allow more complete remote control)

Graphite protocol - supported in CORE and CE

TrueCommand - Yes, it will be maintained until alternative non-cloud solution is available. The TrueCommand update to support Goldeye API is in the works. Goldeye API is fully versioned so that future updates are automatically supported.

That’s good, thanks.

LLDP was simply removed for “reasons”. I created an issue in JIRA:
https://ixsystems.atlassian.net/browse/NAS-127982

I was mistaken about graphite or maybe I wasn’t - I remember there was a release of SCALE that could not export data to an external reporting DB like influx.

SNMP - it would be great if we could get more data, like temperatures etc. without falling back to IPMI. AFAIK lmsensors does that on Linux and can be integrated with SNMP.
Similarly there is a VM-MIB etc.

There is no such thing as too much reporting. Even if the data seems irrelevant at first - as Marcus Ranum put it: “The number of times an uninteresting thing occurs is an interesting thing.”

That’s why I invested a huge amount of time and effort into getting Netflow into my network, for example. Elastiflow is awesome.

Kind regards,
Patrick

Agree on preferring not to use IPMI… however, there are some stats where its the only good source

The two alternatives to SNMP are the graphite/netdata exports and the TrueNAS API. Why use SNMP over the other choices?

P.S: I helped get the 1st Netflow implementation out the door at cisco (1993?). That was a radical change to not rely on SNMP and design for performance.

Because the NMS based on SNMP are ubiquitous? I might have a wrong impression of enterprise infrastructure. We definitely run SNMP :wink: But we are not that large.

I’d agree they were ubiquitous… and still used by networking teams for basic functionality.

I’m not seeing the same demand from storage teams.

Which SNMP manager do you use?

This overview of the current situation seemed reasonable.

For comprehensive visibility, integrate SNMP with:

  • Flow-based monitoring (NetFlow, sFlow) for traffic analysis
  • Agent-based monitoring for application-level insights
  • API-based monitoring for cloud-native environments

Ah … now I get where you are coming from. We are not that siloed :slight_smile:

I manage “the data centre”. Layer 2, layer 3, storage, compute, … everything. We have one operations team and 4 software development teams. Operations provides all necessary infrastructure for development, back office, and hosting customers.

I use Observium. LibreNMS gave me weird values for memory usage specifically with FreeBSD hosts and although Adam Armstrong has a reputation for being difficult it’s a fine piece of software. That’s why I wrote the complete Observium on FreeBSD install guide.

Thanks for the background… I’ll do some research.

Yes, your environment is a little unique. I understand why you do it, but its not our standard deployment model.

Is using graphite reporting out of the question for you?

The use of trueNAS APIs would only make sense if/when you update to Goldeye. That’s probably not next week :slight_smile:

No, no. It’s perfectly good. I just had that idea it had been removed from SCALE at some point. I actually like Grafana, and graphite plain text → influx → grafana works great.

Can you also integrate Grafana and Observium??

That way we can focus on getting the right graphite reporting stats.

Not that I knew. Observium does its own thing with a MySQL/MariaDB database for the data, already aggregated with RRDtool - there is no raw time series data here. You could theoretically use Grafana’s MySQL connector, but what then? There is no database schema documentation apart from the source code.

Kind regards,
Patrick

One of the functions of the TLV parameters sent by LLDP is to obtain the QOS settings of the other end, which is very useful for RoCE

Just following up… I’m not sure if and when LLDP was included.

We don’t have any customer demand, but maybe they would like the benefits. We agree that reporting improvements are wanted/needed.

I’d suggest a Feature Request and lets get votes and examples of where it would be useful.

I’d like your opinion on wehther it needs to be integrated into Middleware and UI… or can be just a cli tool (turn on/off).

There already is one:

It is still in CORE. It works well. Enable and forget. It was in early SCALE releases and then removed.