You will benefit much more directly by letting your instance have that extra memory directly and not via that added extra step of creating that virtual drive. Give your instance more global buffers. Also from the sounds of it you might want to look at your queries and associated query plans in a bit more detail. You should get in touch with the WRC for that, they're great at sorting out why queries run slow ( you might want to reach out to car-part first, maybe they've fixed some of the queries)

The datamodel in COS is such that you have multi-modal access to your data in different ways. Having the ability to access your data via objects (class definitions), SQL (tables), and raw globals is what makes it so powerful. Ultimately the data is always stored in globals. The mapping for the other modes of access are done via class definitions. Class definitions are also transparently mapped to SQL tables. So any time you create a class, a corresponding table is being created and vice-versa. The SQL-concept of "views" is separate from all of this and sits on top. @Robert already pointed out the documentation for storage mapping which actually allows you to customize the relationship between the global structure and a class(/table). This is usually not recommended unless you have legacy data you need to access. The default storage strategy does a very good job to store data effectively.
Note: Just creating a class will not create the global structure just yet, it will only be created once you start putting data in.
Note2: Indices are just additional globals that get added to your class storage.
Note3: If you are having trouble with your indices, it might be a good start to open a WRC issue. They have very good people to help you sort through any issues quickly.

There are quite a few different possible causes for this. A 500 error generally indicates a problem of IIS getting any data from the backend. This could be a permissions issue, or a network issue (among others). Without more information it's hard to tell. If you want to debug yourself, you should start by looking at the CSP Gateway logs (CSP.log), possibly increase the gateway log level (in the gateway management page). This will tell you where to go next.

Of you need a quicker solution it would probably help to contact the WRC (https://www.intersystems.com/support-learning/support/), they debug this kind of thing all the time and will be able to sort you out quickly.

Hi Thomas,

sorry for the long wait here, I just noticed this. From what I am reading about the OData specification, it is just a standard further clarifying on how to further structure your REST api beyond the general REST guidelines. (https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=odata)

As such your starting point to implement this would be the Creating REST Services.

While it has been discussed a couple of times, I'm not aware of anyone having done this already.

Best,
Fab

There really isn't a general answer as to what the 'best way' (tm) is. There are way too many dependencies on that.

It really depends on your workflow and requirements of your backend. Zabbix is very well capable of ingesting SNMP data, just as well as ODBC (https://www.zabbix.com/documentation/3.4/manual/config/items/itemtypes/snmp).

Usually the answer to 'the best way' comes down to: what are you most familiar with? To use ODBC you'd need to implement some glue code on the Caché side, same if you were to go with a REST interface. Since you mentioned you have custom indicators, you'll have to write some code in any case. So, again, it comes down to your preferences and preexisting experiences.

Evgeny already pointed out one of the local SNMP articles to get you started on this.

Cheers,
Fab