Hello. Welcome to this session in the Identity Manager Unknown Unknowns series on Self-help and Diagnostics. So in this session, we're going to run through some monitoring capabilities, some self-help tips and hints. So let's have a look.
We're going to have a look at how to connect to some of our forums, get some information. We'll have a look at some things some monitor, talk a little bit in the same vein about SIEM integration. We'll have a look at NLog debugging. I'm a big fan of debugging. I think we should be doing a lot more of it. Kind of reminder on where to get useful performance information from Sync Editor, and then a little bit on database checking at the end. There's a lot more topics, obviously, we could cover on this, so I think this is a taster, and it's definitely an ongoing topic that we can discuss. Let's go ahead.
So areas that we can go to find information, just quick reminder if you haven't had a chance to look at them all, there's the public forum, where we can go to find information about all the products, identity manager included. There's the support Knowledge Base at support.oneidentity.com, where you will need to log in, but you'll be able to get access then to official Knowledge Base articles from our support guys. In terms of the usability of things like Google, which we can find things, say I was interested in One Identity Manager SAP-GRC stuff.
You can see here we found a link to the public forum that I mentioned earlier. We found a link to some of our YouTube channel detailed presentations on SAP. They're usually quite digestible, individual sessions on identity manager topics, 8 to 10 minutes, so I really recommend you check out the One Identity channel. So these are all things that run into already, but just reminder.
And then finally, the Connect forum, where we can find information as well. It's a forum that's reserved. You need to log into it, and it's for partners primarily to discuss with us problems, ideas, and so on. There's two ways to get into that. Your organization could federate with us. If that's not the case, you can just come on self-service, connect.oneidentity.com, register, you will have to manage your own password, and request access then through your partner manager, and we'll make sure you get authorized. But step one, get a login. Set two, get the authorization as a partner. We'll take care of that for you. And then you'll be good to go.
So just a reminder on the kinds of things we can get or expect in the Connect forum [INAUDIBLE], and then if you click into the products, there is a discussion forum where you'll find-- and you can see it's a very active forum where typically any kind of decent question will get an answer from either partner or ourselves. And then there's also things like Knowledge Base as well. We can go to find information. You can search for things. SAP, so you can find SAP info. We can find-- put some simple helper documents up there.
So you can find these documents, which cover a whole bunch of topics, and then you can see a whole range of topics here. So just a general reminder, there is a lot of information out there. There's a lot of good practice documents. Not withstanding, of course, you're welcome to ask questions and get in touch with us as well, all right? But definitely have a look on those forums first.
Now, let's move on to our topic, 27 things to monitor. We can just switch to a demo of this just to show you what it looks like. So let's go on into a desktop here. We have a little PowerShell script that exposes things. Let's run up this PowerShell. Could make this big screen. You can see there's a little PowerShell running through-- I'll just let it continue there-- running through a bunch of things that we might want to monitor in Identity Manager. I don't think we can cover all the different elements here.
I think the key point to take away is that using a combination of SQL and REST API calls into Identity Manager, we can extract a lot of information about the operations, about the state, about the configuration, and metrics that we could need from a performance point of view. So if I just go back to the slides, we can just go through some of the categories of metrics that this little script here, which is available on the Connect website.
Here's some of the categories of metric that it pulls out-- the things about the operating system, the machine. Is the clock on the machine in sync with the database server? If it's not, that can cause synchronization problems. Actually, that's the kind of information you can also get from the DB journal, as it happens. But you can obviously extract operating system level information to set baseline context for Identity Manager monitoring. So you can see, I'm sort of working up the stack here. So we go to the database level. There's a lot of information about the database. We can extract the version, the state, the amount of disk space that's been assigned, and all of this is available over SQL from SQL Server.
So what I would say is that this is the kind of information that we should have at our fingertips. Some of it is available in standard monitoring, tables in the product, things like the QBM system overview tables, which are exposed in all the administration clients in the Help dropdown. You can see that information there. Of course you can get that over SQL or through the REST API as well. Moving on then, configuration elements. As you know, 50 to 60 configuration items that are there, some of them more or less important, the key ones you will want to pull out so that you can check the state of them to be sure that they're in a good state.
Moving onto job server state, web apps. We could be interested in things like [INAUDIBLE] the web servers and job servers enabled? As you know, it has an emergency stop capability. Is that in operation? That for some reason it's got turned on? These are the kinds of things we should know about. Logs in Identity Manager platform, you know they come from within the database itself. I mentioned the DB journal. Synchronization tasks, we'll write to the database a lot of good information there. But of course, there are logs on the disk as well. Those logs can be centralized, extracted at the database level or potentially using an analog receiver as well if you've gone to the trouble of writing one of those or if you picked one up.
In terms of the runtime, the operations, there are a lot of metrics that we can pull down from the solution as well. And we can check the state of synchronization tasks that are running, how long they've been running, and so on. So there's a lot of things we can monitor, 27 items off the top of my head pretty much just starts to scratch the surface. You can see things there exposed related to synchronization, [INAUDIBLE], data storage, things like membership actions that might be pending.
These are things I think we need to be careful when we do call them to people's attention as to whether it's an error or whether it's something we're keeping an eye on, right? Perhaps if it crosses a threshold because not everything that we're monitoring that does require that we keep an eye on it actually signifies an error. So there's some sort of [INAUDIBLE] there to set thresholds is going to be required, but there are plenty of metrics available in the platform.
All of the configuration items that may be interested in at all those different layers are all easily accessible. I mean, we need these in day-to-day operation, but if in particular some important event's going to happen, like an upgrade, then all of these things should be readily available before we step into that upgrade tasks and so on. So that's just a reminder on that front. As I said, that script, if you're interested in that as a sample, is available on Connect.
In a similar theme of extracting interesting information from Identity Manager, we done-- I'll just give you an example here-- some SIEM integration. So the SIEM systems are very good-- it's [INAUDIBLE] in this case [INAUDIBLE]-- very good at sucking data up over SQL, over REST APIs. And really in my experience, all those guys need, all those SOC teams need, SIEM teams, all they need from us is where do they go to get the data, which table, which REST API call. So if we set them up with that information, they can very quickly do this integration.
So here are just some examples of the kind of metrics that we were asked to provide to SOC team. Login success failure is available in Identity Manager. Actions involving system users and AERoles, so the requirement there was if there was any kind of privileged user in Identity Manager, which are like system users, administrative users, if there was any creation or action on those, if there was any elevation of permissions related to assigning them new authorizations within the Identity Manager, which happens through the mechanism of these so-called AERoles, then they wanted to be alerted of that.
If there were actions involving configuration parameters, hey, if a hacker was turning off auditing, that would be an interesting thing to know about obvious reasons. I mentioned earlier emergency stop-start actions taking place. Somebody trying to interfere with the operation of the system, it'd be good to know about it. Anomalies in audit logs or other logs being tampered with. Native changes on target systems-- we can readily report on this kind of thing in Identity Manager. Changes in OneIM to person entitlements-- perhaps we can't focus on everybody, but let's pick top 100 execs or top important people and focus on those.
And above all, one of the things actually when you sit down to integrate these SIEM systems, what you'll see is that you can get a lot of information from Identity Manager, but some of the well-known identities perhaps we want to ignore because let's hope they're trusted identities and we have other ways to govern them and so on. For example, we'll be watching if any of their access has been changed. So we may well need to filter some of these events coming from Identity Manager. So these are just examples of the kinds of things we've done with SIEM. Again, passing that message once we can find the metrics in Identity Manager, usually the integration with those SIEM systems goes pretty smoothly.
Now, as I mentioned at the start I think, I'm quite a fan of logging, and I think when we do write some scripts, Identity Manager or when we build a new process chain, I think we should be almost obsessive about logging because downstream that will really pay off in terms of helping us to keep the system operational, keep it in good shape. It's two lines of code. You can see line six, get yourself a logger. Line seven, you log the message, and it'll come out in the standard Identity Manager log files, the standard place, whatever receiver you've configured for this logger, it will go there. A file, an analog viewer, a database, whatever the receiver is, it'll just go there automatically.
That code can be called [INAUDIBLE] scripts, maybe from your process change, maybe your templates. It can be called also from any PowerShell that you may be integrating into a PowerShell connector. And that's fantastic because you then see the full flow of Identity Manager and then moving into your PowerShell and moving out, and that's very, very powerful for optimizing the interaction there at the connector level. Another example of logging natively to the Identity Manager job server log file, jobservice.log, [INAUDIBLE] there to log the application name. You're never really sure sometimes which application context is going to be used. It can be interesting to see the app names, which is just a reminder on that one. So yeah, you can never really have too much logging, I think. Better to have too much than too little.
Just a reminder in terms of synchronization, of course, performance of Identity Manager of the different components, it's a big topic. But just to focus in on one thing, if there is one thing we're going to get easily, it's this reporting from a synchronization task on a per object level about how long it's taking to synchronizing these tasks. So as you know, performance is all about breaking it down so we can identify where any bottlenecks are, and the first port of call, at least from a synchronization task point of view, is having a look at the report in the Synchronization Editor logs. So just a reminder that information is there.
Now, in terms of database checking, Identity Manager is [INAUDIBLE] is a very database-centric product, highly normalized tables, a lot of references, and so on, and so there's a responsibility there to keep that database in, let's say, good shape from a database integrity point of view. Now, we do provide-- let me just switch back. This is a little demo mode. We do provide tooling to help with this. So in the designer, if we go into the Check Data Consistency view, then there's this ability to tell Identity Manager to go and check the various aspects of the database.
Now, Marcus will cover off some elements of that in his session for developers, his unknown unknowns developer session, particularly talking around detecting non-optimal uses of queries in your code. So that's really super to be able to check that. It's definitely in the top three, I would say, reasons for poor performance is just a little bit of lack of attention when we write the queries, so the database checkers will help with that. But what I want to talk about here is I think one of the challenges with this tool is just knowing what is a good thing to run and what is a good test to run.
And so what I do, and I think this is a good thing to do in terms of just getting some value from this tool that maybe is nevertheless consumable, is just to click here, sort alphabetically, go to the database section, select all-- you can highlight these guys-- select them all there, all the database checks like that. You can unselect them. I'm going to have to reselect them now. It's OK, just to show you how that goes. Select them all there.
So now you've selected all those items, and actually, if you look in the documentation for upgrades for the product, you'll see that running precisely this database consistency check is what is recommended prior to an update, at least this one. So this is a good one to run in terms of checking your database. So you have it configured, and now we can actually kick off that check there, so you just click on that, and it will run through those tables, checking that any errors who show up here. And then you can zoom in on some of those things that will repair if you, some of them it's calling your attention to, but at least you can get that list and run through that and address any issues.
So that's just a reminder on the database check side. So say that database level check we just showed there is one that's recommended prior to upgrade, and it's one that we run regularly in our demo environments, and I dare say that would be a useful one to run periodically in production to check that everything is ticking over well. So that concludes that short self-help diagnostics presentation, and I look forward to catching you again for another vUNITE presentation. Thanks for your attention.
17:30