I think Badger is correct. But there is also the memory-based cache to consider, and if there is a warning that there is no-such template known, that would indicate that the template never got entered into the memory cache, so there would appear to be two problems.
Thinking the persistance code-path through a bit:
- the templates get written to disk by do_persist
- do_persist is called from both persist and do_register
- do_register is not called from LogStash::Codecs::Netflow#register (L61) but is called from TemplateRegistry#register (L567)
- register docstring indicates that that if invalid_template is thrown it won't be cached
- register is called from the the template processing parts of decode_ipfix (L306) and decode_netflow9 (L203)
- persist itself seems never to be called, but that shouldn't matter; persistence should still occur when a new template is received.
In decode_ipfix, it would seem (I'm not a Ruby developer yet), that ipfix_field_for (L299) must succeed in order to reach the call to @ipfix_template.register. It is in ipfix_field_for that we see the warning mentioned:
Unsupported enterprise field {:type=>638, :enterprise=>5951, :length=>2}
Enterprise number 5951 is indeed Citrix. The code would suggest that it will only take enterprises-type pairs that it knows about in @ipfix_fields (note: now we're talking about fields, not templates). The fact that the warning is about an unsupported field, rather than an unsupported enterprise helps to narrow the focus..... I think 638 is a type that came later in the development of the Citrix Netscaler (Application Delivery Controller) appliance.
So where are these fields defined? L73 tells me in netflow/ipfix.yaml, which has been provided. But you'll see that the section of that file that pertains to Citrix (5951) is L1260-L2157, and the newer types are not included.
So if you're not seeing any persistance, it would suggest that the only templates you have configured to be sent are for those that come after 541.
What needs to happen is for a complete set of those types to be dug up. That's the problem with AppFlow, as this mapping is not published (or at least, was not published in an up-to-date form when I last looked for it some years ago).
You might wonder why we need this mappings at all, isn't IPFIX meant to be flexible? Well, yes and no. The template records that get sent out are a bit like structure definitions, but they only tell you that a particular message is formulated from a particular set of fields (Information Elements, or IEs for short, or those specific to each Enterprise, or EIEs), not what those fields are (how big they are, what sort of datatype it contains or what you might call them).
Thus, the receiver needs to know the following:
- how to interpret each IE (all of them within each fieldset it receives)
- what to do with each IE (eg. what name to give it, or what it means semantically)
You can gain some partial appreciation for what it was done this way when you look at the history of NetFlow (in particular the various subversions within NetFlow version 8).... but it still leaves a bit of a sour taste in the mouth of us that don't necessarily want to point an IPFIX exporter at something that isn't a vendor element manager (that is coded to know what to do semantically with the IEs it receives).
If you can't find the information you're looking for (I once tried asking our technical account manager, but nothing came of that), then you'll just have to reverse engineer it from the template messages that come out and then make successive guesses..... good luck; you'll appreciate why I don't much like AppFlow for logging. These days, I would only use it for Load Balanced Virtual Servers that aren't HTTP (and thus can't include the client IP in a request header).
If memory recalls, I think Splunk had some table of these: https://github.com/splunk/ipfix, but that's out of date too and hasn't been updated in 7 years or more, and Splunk has since dropped support for IPFIX.
Reading between the lines a bit, I see that that Citrix have introduced a 'logstream' transport for AppFlow, as a alternative to IPFIX.... I can imagine why that would be attractive for various reasons, so its not unreasonably to consider AppFlow as being less-and-less useful in future.
PS. I'm really not sure what kind of template you're interested in, but if you're wanting performance-management, you may get better ROI by focussing on RUM instead.
Continue down the AppFlow path only if you are suitably desperate and if no other mechanism will suffice (submit a support ticket to see how to do what you might want using syslog logging or such).
OR, consider how you might instead get the insight you need from Netscaler MAS... though I have no experience trying that.
Hope that helps 
Cameron