Destination logs insert _ character
Example:
time=2021-11-03T10:23:14.718Z | lvl=INFO | corr=XYZ; cbnotif=1 | trans=ABC | srv=N/A | subsrv=N/A | op=processNewBatches | comp=Cygnus | msg=com.telefonica.iot.cygnus.sinks.NGSISink[606] : Finishing internal transaction (DEF; cbnotif=1, FFF; cbnotif=1, ) Sink: com.telefonica.iot.cygnus.sinks.NGSIPostgisSink Destination: yyy_/_parking_onstreetparking
Must be: Destination: yyy/parking_onstreetparking
Doubt: For all sink types?
bug in a log ?
I think, because not exist something as yyy_/_parking_onstreetparking
Printed by
https://github.com/telefonicaid/fiware-cygnus/blob/29eaf8368e5e0e71304856e65c26ecb7011640da/cygnus-ngsi/src/main/java/com/telefonica/iot/cygnus/sinks/NGSISink.java#L421
and
https://github.com/telefonicaid/fiware-cygnus/blob/29eaf8368e5e0e71304856e65c26ecb7011640da/cygnus-ngsi/src/main/java/com/telefonica/iot/cygnus/sinks/NGSISink.java#L614
But tablename is build at (i.e. for postgis) https://github.com/telefonicaid/fiware-cygnus/blob/29eaf8368e5e0e71304856e65c26ecb7011640da/cygnus-ngsi/src/main/java/com/telefonica/iot/cygnus/sinks/NGSIPostgisSink.java#L610-L625 and depends on datamodel configured for that sink
The issue is still ongong in our prouction environment with 2.16.0 cygnus_version
Could you provide for this case https://github.com/telefonicaid/fiware-cygnus/issues/2108#issue-1043368887 what is the name of service, subservice, entity_id, entity_type, database name and so on (not real, but with examples) ?
There are several cases:
- postgis : xxxx_/yyyyyyyyyy o xxxx_/_zzzzzzzzz
- mongo(sth): aaaaa_/bbbbbbb o kkkkk_/
- ckan: ssss_/fffffff
- arcgis: _ggggggg
- mysql: lllllll_/ssssssss
yyyyyyyyy is a subservice? zzzzzzzzz is a entity_id, or an entity_type?
For example in a log with " Sink: mysql-sink Destination: smartcity_/_thing:dispB_thing" and default data model (dm-by-entity) service: smartcity subservice: / enttiy_id: thing:dispB enttiy_type: thing And seems right to me
Summarizing character '_' is used by cygnus in destination (and then in logs where destination appears) to contact depending n datamodel used the several atoms:
<service>_<subservice>_<entity_id>_<entity_type>
<service>_<subservice>_<entity_type>
<service>_<subservice>_<entity_id>_<attribute>
having in account that subservice contains always '/'.
So destination word in logs should be read in this way