What can we do to make your life easier developing in IKL? If you were granted 3 wishes, what would they be?
They can either be tools, better debugging, process, training, documentation, testing tools, literally anything…
I would be more than happy if we could add:
- devops tool (visual tools) to (a) view stored metrics per device (value/time/tags) in table format (b) add metric using a web-form in order to test scala alarms
- ability to create alarms using something like “expressions” or something more dynamic (apart from scala rules)
2 Likes
I’m finishing to test my first IKL script and in my opinion worst problem is about documentation. With documentation we have mainly one problem:
- Is not intuitive, sometime is hard to find the information that you are searching. All information to develop is there into Confluence but, maybe is necessary to re-order.
About @Vasileios_Bouloukos second point, my +1 to expressions to create alarms. It could be very useful from customer side to have a way to generate alarms simplier, take into account that is not usual into customer staff to have a network/security administrator with developing skills.
2 Likes
I would be equally happy 
Just to clarify, (a) would allow you to see that you have correctly corrected the metrics.
(b) would then allow you to see that your metrics are fed to the rule. You want to have the ability to trigger the rule on demand. A common complaint is that you don’t know when the rule is executed, sometimes, you have to wait for hours.
Jorge,
Congrats on your first IND script. Good stuff…
Definitely there’s room form improvement with respect to documentation. Open to any suggestion. How about we discuss this in the next meetup.
@Hawkeye_Parker is passionate in this area
Thank you for your feedback.
Agree with Vasileios_Bouloukos 1.devops tool (visual tools), i would be curious to see that.
In order of priority:
1 - Some way to create re-usable chunks of code that we can share between/across scripts. I.e., some way to import methods or classes into IKL. Some way to (really) unit test this shared code. This is by far the most important to me.
2 and 3 - Improve the overall system testing/debugging process. This is far and away the most time consuming part of the dev cycle for me. This means: make it easier to get an alert screenshot, and when things go wrong, better tools to debug. This would include some more centralized/simple/fast way (think: debug dashboard) to:
a) run a quick, end-to-end integration test that will tell you: will a given script “hit” a given rule and trigger an alert? Maybe this could be a command-runner extension, and maybe these tests, like existing unit tests, could run as part of CI.
b) view metrics, db data (device ID, delete/reset existing alerts), interrogation tags, etc. for a given device
c) see which rules are actually running on a server, which .ind scripts are “connected to” which rules, and what a given rule is expecting (in terms of metrics and metric tags) from the .ind script
2 Likes
You are right! Exactly as you described it.
I’ll second this!
Good ideas