[00:00.000 --> 00:07.760]  My name is Victor Kirchenstein.
[00:07.760 --> 00:15.800]  I'm from NetXMS team and it's a brief introduction who we are and what we're doing.
[00:15.800 --> 00:24.040]  So it's a network monitoring system and it started in 2003 as my personal hobby project
[00:24.040 --> 00:29.880]  and I was working as a network engineer in a local system integration company at that
[00:29.880 --> 00:31.880]  time.
[00:31.880 --> 00:39.520]  Now it's a small team working full time on this project and we are based in Riga, Latvia
[00:39.520 --> 00:48.440]  and you can check our website, you can check the source code on the GitHub.
[00:48.440 --> 01:01.880]  So the design principles that is in our system is we want to make it fast, flexible, extendable
[01:01.880 --> 01:12.760]  by user in different ways when possible without changing the core source code, suitable for
[01:12.760 --> 01:20.520]  large setups, so it should be able to monitor large networks, large installations and we
[01:20.520 --> 01:26.120]  put a lot of emphasis on network monitoring and on distributed monitoring.
[01:26.120 --> 01:33.560]  So you can monitor pretty much anything in your infrastructure, servers, workstations,
[01:33.560 --> 01:41.000]  some devices, etc., but it still has some very network specific functionality built in.
[01:41.000 --> 01:45.080]  So what are major features of the system?
[01:45.080 --> 01:52.840]  So we have automatic network topology discovery, so we can discover new devices in the network
[01:52.840 --> 01:59.360]  and also how they are connected together on different levels, so it layers two of the
[01:59.360 --> 02:08.240]  OC, so like Ethernet, serials, etc., it's an IP level, it's an OSP of topology and system
[02:08.240 --> 02:14.720]  also provides visualization of this topology on different levels.
[02:14.720 --> 02:23.360]  We have topology-based network, topology-based event correlation, many useful topology-based
[02:23.360 --> 02:30.080]  lookup tools like to find specific MAC address in the network, find specific IP address,
[02:30.080 --> 02:37.000]  check the switch forwarding database, check OSP of neighbors all from monitoring system,
[02:37.000 --> 02:43.320]  user interface, all searchable.
[02:43.320 --> 02:48.520]  We have our own agents that can be installed on different operating systems and those agents
[02:48.520 --> 02:55.760]  among other things can act as caching proxies for most of the protocols that are supported
[02:55.760 --> 02:57.120]  by the system.
[02:57.120 --> 03:05.320]  So you can have a remote proxy that communicates with SNMP devices in the remote side and your
[03:05.320 --> 03:10.360]  secure communication channel with a monitoring server and if you have lost your connection
[03:10.360 --> 03:15.160]  to your remote side it will keep collecting data and caching locally and then re-synchronize
[03:15.160 --> 03:19.240]  to the central server when you have your connection back.
[03:19.240 --> 03:26.360]  The system is very even-centric and we have powerful functions for even processing it
[03:26.360 --> 03:32.920]  quite flexible.
[03:32.920 --> 03:35.920]  We support data collection from different sources.
[03:35.920 --> 03:43.720]  It could be our own agents SNMP, MQTT, SSH commands, Internet IP, web services, data
[03:43.720 --> 03:48.920]  can be pushed to the system via our API.
[03:48.920 --> 03:55.920]  We have very powerful data collection templates to simplify and automate data collection
[03:55.920 --> 04:00.920]  from devices and servers.
[04:00.920 --> 04:08.120]  After data is collected the further processing is uniform so as long as we get the value
[04:08.120 --> 04:14.880]  for the metric it's no longer relevant how we get it with which protocol you process
[04:14.880 --> 04:17.880]  it in the same way.
[04:17.880 --> 04:24.520]  We have many options for data transformation and for threshold checking.
[04:24.520 --> 04:31.680]  We have built-in scripting language in the system that can be used for implementing any
[04:31.680 --> 04:40.360]  custom complex logic for data transformation for even processing for automation.
[04:40.360 --> 04:48.960]  We provide tools to build automation on top of the system and we have very flexible access
[04:48.960 --> 04:58.720]  control in the system so it actually can be used and some users do use it as a multi-tenant
[04:58.720 --> 05:07.720]  so if you are MSP for example you can provide access to parts of the system to your customers
[05:07.720 --> 05:12.040]  as they see the network.
[05:12.040 --> 05:19.880]  This is an architecture kind of overview so we have a monitoring server in the center
[05:19.880 --> 05:25.960]  and it can collect data with different protocols directly or through our agent.
[05:25.960 --> 05:34.520]  It uses SQL database for storing data and configuration and we among other databases
[05:34.520 --> 05:40.360]  we support Postgres with time scale DB extension which is what we really recommend if you have
[05:40.360 --> 05:51.440]  big setups and system administrators and operators can access the system via web interface
[05:51.440 --> 05:57.080]  or desktop application and we also provide full API so whatever you can do from web interface
[05:57.080 --> 06:03.480]  you can do from API and so it's really good for integration.
[06:03.480 --> 06:13.120]  I want to go through a few use cases of our users so the use case one it's a global company
[06:13.120 --> 06:17.560]  with offices around the world and they have more than 12,000 network devices in their
[06:17.560 --> 06:25.720]  global network and they use NetXMS to monitor all these devices, more than 2 million metrics
[06:25.720 --> 06:30.960]  being collected from it.
[06:30.960 --> 06:38.320]  We have a link to InfluxDB like the fan out driver for sending data so besides storing
[06:38.320 --> 06:46.480]  it in a NetXMS database it's also sent to the InfluxDB for further analysis and processing.
[06:46.480 --> 06:55.680]  Case number two is completely different it's an agricultural holding in South Africa and
[06:55.680 --> 07:03.160]  they use NetXMS to monitor too much everything they have network devices, servers, etc.
[07:03.160 --> 07:08.200]  Including the solar panels and the fridges and the power generators and we use different
[07:08.200 --> 07:13.040]  protocols and different methods for getting this information so like MQTT for solar panels
[07:13.040 --> 07:18.640]  and for fridges for power generators you just trust BDP computers with NetXMS agent installed
[07:18.640 --> 07:26.200]  and like generators and fridge sensors connected via GPIO.
[07:26.200 --> 07:34.160]  The third case is industrial computing consulting company in the US and they use NetXMS in a
[07:34.160 --> 07:41.880]  way that was unusual for us as a site assessment tool so basically their consultant comes to
[07:41.880 --> 07:49.080]  the customer side with a laptop with NetXMS server installed, run it in a discovery mode
[07:49.080 --> 07:58.120]  for a day or for a few hours and it finds the industrial devices and collect information
[07:58.120 --> 08:06.520]  using different protocols from them and also builds the topology map for them automatically.
[08:06.520 --> 08:14.960]  And the final use case is the quite big ISP that operates in USA and Central America and
[08:14.960 --> 08:22.920]  they monitor all their network devices and other equipment with NetXMS.
[08:22.920 --> 08:32.800]  They have more than 70,000 devices all monitored with a single monitoring server and they use
[08:32.800 --> 08:42.400]  a lot of automated discovery, automated templates.
[08:42.400 --> 08:49.840]  So let's see that was really quick overview, you take a look at our website, ask questions
[08:49.840 --> 09:02.320]  after the session, take stickers, hey thanks a lot.
[09:02.320 --> 09:06.080]  That was the first ad hoc talk, thanks for doing this.