[dev.icinga.com #13233] Missing "display_name" field in Service tab

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/13233

Created by plarivee on 2016-11-17 18:56:02 +00:00

Assignee: (none)
Status: New
Target Version: (none)
Last Update: 2016-12-04 13:43:08 +00:00 (in Redmine)

---

there is no "display_name" field in the service tab when creating / editing services

[icinga-migration]

Updated by tobiasvdk on 2016-12-02 10:52:43 +00:00

As discussed with @tgelf this is a feature. You can have any character in your service object name so it's not necessary to have an extra property. What do you think? Do you have an use case?

[icinga-migration]

Updated by plarivee on 2016-12-02 11:18:29 +00:00

Only use case I cold see right now is being able to have "display_name" that are not unique. Not that big of a deal.

example: I have a service with "apply for" that loops vhost MetaArray in Director. the service name is "VHOST: $config.http_vhost$ $config.other_unique_info$" but I might want the display_name to be only "VHOST: $config.http_vhost$" for visual cleanless. (if checking let say the same vhost but different parameters, without having them in the display_name.

for the momment I inject directly in the database my service templates for director, so I can already set display_name like that. I manage them with puppet.

[icinga-migration]

Updated by tobiasvdk on 2016-12-02 13:08:42 +00:00

plarivee wrote:

Only use case I cold see right now is being able to have "display_name" that are not unique. Not that big of a deal.
Sure, but is there any use case? :) ... I also thought it's missing but thinking about it, it makes sense to obsolete the display name.

example: I have a service with "apply for" that loops vhost MetaArray in Director. the service name is "VHOST: $config.http_vhost$ $config.other_unique_info$" but I might want the display_name to be only "VHOST: $config.http_vhost$" for visual cleanless. (if checking let say the same vhost but different parameters, without having them in the display_name.
This would confuse the user looking at the "same" services, wouldn't it? Do you use this right now?

for the momment I inject directly in the database my service templates for director, so I can already set display_name like that. I manage them with puppet.
You can also use the REST API for this.

[icinga-migration]

Updated by geotek on 2016-12-04 10:07:01 +00:00

I would not miss the display name if obsoleted. As it is now, it does more harm than good. For example when manually cloning an object it happened more than once that the new object kept the display name of thr original object which was not intended. If the displayed names are not unique this ambiguity is calling for trouble in real world scenarios IMO.

[icinga-migration]

Updated by plarivee on 2016-12-04 13:43:08 +00:00

I disagree, Having the option to set display name is way simpler and less confusing when using apply rules for our end user.

the configuration can then contain a { display_name: "google.com check port 80 blablabla" }
In our apply rules we have " name: "VHOST $config.http_vhost$ : $config.other_unique_id_set_by_other_system$"

That way we don't need our end users to enter the $config.blablablab$ envrytime they configure something.

Name is for internal working of icinga and display_name is the friendly name, that is not neccessarly unique.

geotek wrote:

I would not miss the display name if obsoleted. As it is now, it does more harm than good. For example when manually cloning an object it happened more than once that the new object kept the display name of thr original object which was not intended. If the displayed names are not unique this ambiguity is calling for trouble in real world scenarios IMO.

[vita2]

it would be nice to have the display_name argument as a optional field 👍

[druchoo]

I'm trying to create the Cluster Zone check(s) as described here. Is there another way to do this with a dynamically generated name without display name?

apply Service "cluster-health" {
  check_command = "cluster-zone"

  display_name = "cluster-health-" + host.name

  /* This follows the convention that the client zone name is the FQDN which is the same as the host object name. */
  vars.cluster_zone = host.name

  assign where host.vars.client_endpoint
}

[bahrpatrick]

I would really appreciate this feature in the Icinga2 director.
Is there any workaround to set the "display_name" at the moment?

[Hitokun]

for anyone wondering, like @bahrpatrick. You can get the id of the service apply (look at your browser's address bar for it when looking at the apply in director, eg: http://172.17.0.2/icingaweb2/director/service?id=88).

With that reference you can POST to the API like (forgive my pseudo-curl) curl -s user:pass -XPOST -H content-type:application/json http://myicinga.com/icingaweb2/director/service?id=<id> -d '{"display_name": "My Service Display Name"}'. It is not hard to do, but it is pretty time consuming.

My use case involves having different apply rules (where the custom fields are different) where I want the same display name among them all.

I do agree this would be pretty cool to have in place. I'm not very familiar with Director's codebase, so I don't know how hard it would be to add the field to the Apply Rule view (assuming that's the only thing required). I might spare a couple of hours one of these days (no guarantee's, though) and try to add this. Would be a fun 😬.

[rcalpha]

Currently, display_name in service is usefull for me. An example of my use. In a switch, I monitor each port with name "port--". Instead showing as service "port--" , I use display_name to set a meaninful name like "Port : Link to router X"

This works without Director with manual configuration. I'm migrating to Director to make life easier with configuration.

[Thomas-Gelf]

Please see here.

And please do not hijack other peoples issues, this one is about the display_name property.

[Mikesch-mp]

This is badly needed. Not every passive result sender can handle umlauts or specialchars in service names correctly.

Any change we see the ability to set display_names in director in the near future?

[slalomsk8er]

I'm migrating to the director and in my old config I use conventions to apply service groups depending on service names.
Also I use friendlier display names for the users:
app1_interface_files_csv_from_app2_error vs Applikation 1: Schnittstelle CSVs von Applikation 2 in ./error

• app1 = the Applikation this check belongs to
• interface
• file = type of interface
• csv = type of files of this interface
• from = direction of interface from the perspective of app1
• app2 = the other party
• error = this interface moves files into ./error or appends .error and we check for this - many interfaces have 3 checks - files age in main folder, no new files in done folder and file in error or files ending on .error

Also now I have the problem that I need a way to create URLs from service names, that are icingaweb2 compatible for use in notification scripts. Maybe a missing DSL convenience function?

[EmTeedee]

I'd really appreciate display_name for services because of icingaweb2-module-graphite not supporting special characters (e.g. parenthesis) in service or host names. See commit 5a29c432 for icingaweb2-module-graphite.

[agougo]

We are also finding more and more use cases where we need to change the name or the display_name through the director to accommodate requirements. Is there a roadmap to get this added?

[christianhennen]

I'd really appreciate display_name for services because of icingaweb2-module-graphite not supporting special characters (e.g. parenthesis) in service or host names. See commit 5a29c432 for icingaweb2-module-graphite.

Same with the Grafana plugin. Since I switched to the director, graphs can't be rendered anymore because every service now is called like the display_name in the old config, eg. 'Total processes' instead of 'procs'. I'd rather not change the name of the apply rules just to make graphing work again but meanwhile confuse users of the web interface with shorthand names for services.

[christianhennen]

Nevermind, I fixed it elsewhere. If anyone has the same setup and problem:

1. The writer for InfluxDB should use the check_command name as measurement (which is the default I think).

object Influxdb2Writer "influxdb2" {
  host = "127.0.0.1"
  port = 8086
  organization = "Org"
  bucket = "icinga/autogen"
  auth_token = "123456"
  //flush_threshold = 1024
  //flush_interval = 10s
  enable_send_thresholds = true
  enable_send_metadata = true
  host_template = {
    measurement = "$host.check_command$"
    tags = {
      hostname = "$host.name$"
    }
  }
  service_template = {
    measurement = "$service.check_command$"
    tags = {
      hostname = "$host.name$"
      service = "$service.name$"
    }
  }
}

2. In the Grafana panel definition, use ${command} instead of ${service}, since it is automatically available as a variable.

from(bucket: v.defaultBucket)
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r["_measurement"] == "${command}")
  |> filter(fn: (r) => r["_field"] == "value")
  |> filter(fn: (r) => r["hostname"] == "${hostname}")
  |> aggregateWindow(every: v.windowPeriod, fn: mean, createEmpty: false)
  |> yield(name: "mean")